Re: [GMG-Devel] API proposal

[Tryggvi Björgvinsson]

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