Re: [GMG-Devel] API proposal

[Christopher Allan Webber]

Interesting.  This email clarifies a lot... thanks!

Tryggvi Björgvinsson <address@hidden> writes:

> On 11/07/2011 03:00 PM, Christopher Allan Webber wrote:
>> Regarding: "MediaGoblin is user based but who is the user when files are
>>    sent in by users on a specific site? Use OAuth/OpenID? Perhaps tie
>>    closely with OStatus federation."
>>
>> A slight amount of this distinction can be possibly handled by just
>> having one general user in this case, like /u/uploader/.  If the user
>> server doesn't really care what the username is... that way we might be
>> able to meet this type of need without making massive rewrites to
>> mediagoblin itself?
>
> Yes, this is an adequate solution I believe, but that means that the
> attribution field must be required in order to attribute the original
> author/uploader.
>
> I think this will depend on how the federation will be implemented
> (I'm working on breaking things up nicely). One of the things a
> federated service must take into account is how to represent a remote
> user in the system. A nice solution to the remote user model might
> also be useful for these user uploads (hence my point about the
> OStatus federation connection).
>
>> This is good food for thought... I might have more to say in a bit but I
>> leave it to Nathan to think it over mostly.  We might make some
>> distinctions between "claim" and "submission", but it's possible that
>> just the "management" of claims (such as expiring unclaimed media as you
>> described that) could be handled on the user server side of things, if
>> that's what you intend?
>
> Well I don't think it's wise to let user servers manage unclaimed
> media. What I mean when I say manage expiring unclaimed media, I'm
> thinking about just removing files after some time in case nobody has
> claimed them.
>
>> (I'm also curious what the User Server would do that MediaGoblin itself
>> wouldn't be doing?)
>
> For example, our "user server's" core service is to help schools build
> the national curricula, i.e. to enable teachers to define and create
> courses and programmes for the whole educational system (to
> collaborate and share the curricula). For this we're creating a
> curricula builder but on the side we want to allow teachers to share
> course material as OER. This could be images, videos, audio or
> whatever and this media content would be related to courses.
>
> We would then like to have a MediaGoblin instance running that would
> handle the OER media and our curricula site (the user server) could
> focus on the curricula and just point to the content on the
> MediaGoblin instance (teachers would upload media through a specific
> course which would then be handled by MediaGoblin and the course
> object would just provide links to it).
>
> I don't see why MediaGoblin should have to do anything with a national
> curricula, but processing and storing the OER media is something
> MediaGoblin would gladly do.
>
> I might also be too affected by the old unix philosophy: "Write
> programs that do one thing and do it well."
>
> So, before this gets too long (which my emails always tend to become),
> I want to clear things up a bit. Joar asked me earlier on IRC whether
> my API proposal was a RFC or a mistake, since it assumes a different
> application structure than the current GMG structure.
>
> My background is in developing this curricula site that wants to allow
> OER sharing and caring. We were designing a special media server
> (backend) to handle and store all multimedia content for the OER part
> of the site (for load balancing and to allow other open content, but
> non-OER, sites to use a CC media repository/backend). Last week, I
> started looking into GMG as a replacement for this specific media
> server and that will depend on where GMG is going (and I'm just here
> to find out where it's going and hopefully help out).
>
> The API I wrote up is based around our original approach (before
> discovering GMG) and I see it as something Nathan Yergler can look at
> and work from to create the *real* API. I am not requesting a total
> rewrite of the application structure or anything of that sort. This is
> a use case for a specific scenario which GMG might or might not try to
> provide an API for. It's then up to GMG to decide whether to allow
> this scenario or not.
>
> /Tryggvi