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

[Christopher Allan Webber]

We had a chat on etherpad planning this out:
  http://piratepad.net/kuneco

Here's a record of the conversation.  Now we just need to move things
into tickets and start work on it!


Kuneco
http://lists.mediagoblin.org/pipermail/devel/2011-December/000110.html

Total scope
-----------
 - Feed support
   - Atom
   - Activitystreams
   - Salmon (uses magic signature)
   - Magic signatures
 - PubSubHubbub
 - WebFinger

Webfinger
---------
 - XRD generation
   - Example XRDs, currently Jinja2 templates
     - http://mg.wandborg.se/.well-known/host-meta
     - http://mg.wandborg.se/api/webfinger/xrd?uri=address@hidden
 - WebFinger lookup

Feed API
--------
What should this look like?

 - We know we want to be able to chain things like: atom (-> activity
   streams) (-> media specific stuff) -> salmon
   - Signals of some kind?
     (Chris: Sounds interesting, not sure how it could be accomplished)
     [Joar: By registering callbacks to a specific event handle, then
     "emitting" the event calling all callbacks with appropriate
     arguments. Like GObjects message bus]
     Basically, gstreamer for feeds (feedstreamer? ;))
   - Task prioritization?
   - Namespacing attributes passed to each one to avoid conflicts?  (and is 
that too complex?)

 - Should use lxml's DOM to allow each component of the chain to fiddle
   with the tree
   - A bit like webob's request variable <- exactly, modifications along the 
chain
   - We can use inconexo's start of the lxml atom feed generator (borrowed from 
werkzeug)

 - Should we...[joar: This is regarding chaining too, right?] [Chris: Yup]
   - Use subclassing?  But that doesn't handle maybe nicely sticking the
     media stuff in the middle of some salmon feed
   - Use a chain of functions??
   - Use subclassing + events?

Maybe something like:

>>> feedme = FeedGenerator(
...   [AtomFeed, ActivityStreams, MediaFeed, Salmon],
...   title="monkeys", bar="foo")
>>> feedme.add_item(
...   title="foo", media_type="mediagoblin.media_types.video",
...   bleh="heh")

So, each one of the elements in the chain can pass things along using **kwargs ?

Does this make sense??

This way, AtomFeed would add general structure, ActivityStreams might
add some extra stuff on general feed init, and on the individual ones
the same thing... but maybe the media_type one in this particular case
is smart and dynamically loads some attribute changing depending on what
the media manager specifies?  (So, MediaFeed is a mediagoblin specific
thing, for example, not general)?