Re: [GMG-Devel] API proposal

[Christopher Allan Webber]

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?

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?

(I'm also curious what the User Server would do that MediaGoblin itself
wouldn't be doing?)

Thanks for this writeup!
 - Chris

Tryggvi Björgvinsson <address@hidden> writes:

> On 11/07/2011 06:49 AM, Nathan Yergler wrote:
>> Thanks, Tryggvi. I took a super brief look and one question that
>> immediately popped up is whether or not the US/MGS distinction is
>> something that exists today in the GMG codebase. It's totally
>> conceivable to me that it does and I haven't run across it, I just
>> wanted to try and understand how much of this is your specific use
>> case (which if I recall correctly from the IRC meeting is using GMG as
>> a backend?), and how much is the current GMG data-model. Re-reading
>> now, I think the US/MGS distinction (and file claims) are specific to
>> your use case, so I guess I'm just looking for confirmation.
>
> Hi Nathan (and everybody),
>
> I am unsure whether this distinction exists or not in the current GMG
> codebase. I would think, just off the bat, that it would require some
> rewrite or additions to the GMG data-model. I base this on the running
> MediaGoblin instance I looked at where the URI is directly related to
> a specific user on the system,
> e.g. http://mg.wandborg.se/u/dabnotu/m/p1460345-gimp/ which is
> uploaded by a specific user: dabnotu and probably closely tied to this
> user. This might not work for a "generic upload where files can be
> claimed later by remote users".
>
> You are correct that the API is based on a use case where GMG is being
> used as a backend, meaning that GMG stores all media on behalf of the
> "frontend". Think Status.Net storing multimedia content on a GMG
> instance so that Status.Net can only focus on delivering dents and
> then point to multimedia content on the GMG instance. GMG takes care
> of upload and processing and notifies the Status.Net instance when the
> file has been processed.
>
> This might not be the direction we foresee for GMG and probably needs
> some discussion (and input from the project leaders). I just wrote up
> the API based on these needs, since I'm developing the user service
> which needs the multimedia repository backend which takes care of the
> processing.
>
>> Thanks again for putting that together, I think it's very helpful.
>
> No problem, don't be afraid to tear it apart and improve it.
>
> /Tryggvi
>
> _______________________________________________
> devel mailing list
> address@hidden
> http://lists.mediagoblin.org/listinfo/devel