[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [GMG-Devel] API proposal

From: Tryggvi Björgvinsson
Subject: Re: [GMG-Devel] API proposal
Date: Mon, 07 Nov 2011 16:20:52 +0000
User-agent: Mozilla/5.0 (X11; Linux i686; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]