Re: [GMG-Devel] Kicking off "Kuneco": an atom and ostatus library for python

[Christopher Allan Webber]

As a lazy followup:

<paroneayea> joar: maybe step 1 is to rant directly into the channel what I
             mean by kuneco feed stuff
<paroneayea> that usually helps.
<paroneayea> so basically the idea is that pubsubhubbub stuff stems off of
             atom stuff, and different media entries and etc are going to need
             to extend feeds
<paroneayea> if you look at inconexo's code:
<paroneayea>
             
https://gitorious.org/~inconexo/mediagoblin/inconexos-mediagoblin/blobs/feed_library/mediagoblin/tools/feed.py
<paroneayea> currently it's a port-over from werkzeug
<paroneayea> but
<paroneayea> now that it's lxml
<paroneayea> for each entry generated
<paroneayea> after the first pass of say  [12:20]
<paroneayea> AtomFeed.generate_feed_entry():
<paroneayea> that passes back an entry
<paroneayea> so, since it's lxml, and that's an elementtree DOM object
<paroneayea> why not just pass that along a chain to the next thing that wants
             to modify it?
<paroneayea> so AtomFeed creates initial version of feed entry, then passes it
             over to the PubSubHubbub filter, which passes it over to the
             media entry thing
<paroneayea> each one of them can have access to the general feed context and
             the context of that one entry
<paroneayea> and modify the entry individually
<paroneayea> same with salmon and magic signature stuff
<joar> yeah
<paroneayea> how that exactly would happen... a list of callable functions?
             What?
<paroneayea> I'm not sure
<paroneayea> but I think we should take advantage of the DOM to make something
             that can chain along modifications
<joar> paroneayea: What parts of mediagoblin have use for accessing these?
<joar> probably media types
<joar> and all the OStatus related things.
<paroneayea> joar: yeah
<paroneayea> well
<paroneayea> joar: the main thing is
<paroneayea> atom [-> activity streams] -> media/plugin modification [->
             salmon]
<joar> \o/ sounds good
<paroneayea> I'm going to lazily copy-pasta that to the mailing list for
             clarification.

and done ;)

Christopher Allan Webber <address@hidden> writes:

> Yo all,
>
> So we're starting to move into federation territory.  To acheive OStatus
> support, we're going to need to implement a significant number of
> things.  We might as well implement them separately outside of
> MediaGoblin; the more people are using OStatus, the better that is for
> MediaGoblin.  As such I'm creating a new library where maybe work can be
> done in:
>
> https://gitorious.org/kuneco/kuneco
>
> Kuneco means "togetherness" in Esperanto (thanks to Aleksej Serdjukov
> for the naming suggestion).
>
> Some things that will take enough effort to merit breaking out into a
> separate library:
>
>  - Atom support (we're currently using Werkzeug's atom support which
>    is fairly inflexible.  inconexo did a rewrite of it that uses lxml
>    and I offered to contribute it back, but the werkzeug authors
>    thought it should be broken into a separate library (and that if it
>    were they'd consider deprecating their own atom module and pointing
>    to the rewrite))
>  - Activitystreams support (an extension of Atom)
>  - PubSubHubbub support
>  - Salmon support
>  - Magic signature support
>
> I think it makes sense to include those last things with the
> more-extensible atom library as it's going to have to build off of it
> anyway, as far as I can tell.
>
> Webfinger is simple enough where we can just do that inside
> MediaGoblin itself but these other things are probably complex enough
> to merit being split out into something else.
>
> For the moment we're kicking off with Atom support.  Also, I wasn't sure
> what license to pick, but I decided to go with modified BSD since I was
> waffley, but mostly because we're actually starting out with code from a
> modified-BSD-licensed codebase.  I'm not sure though, maybe Apache 2.0
> is more reasonable for this because of the patent provisions.  I'm
> fairly convinced however that it should be permissively licensed
> though.  I strongly believe MediaGoblin being under the AGPL is the best
> choice, but a library that pushes OStatus... there's well, a "network
> effect" with federation (pardon the pun) and I think we'll do best for
> user freedom to have as much adoption as possible.
>
> Anyway I guess this isn't officially part of the GNU project at the
> moment as it's a separate library and we haven't gone through the
> process for it, but I'd like to develop it side-by-side MediaGoblin.
>
> There's nothing in the repository yet, but that's the plan.  Thoughts?
>
>  - cwebb
> _______________________________________________
> devel mailing list
> address@hidden
> http://lists.mediagoblin.org/listinfo/devel