[Top][All Lists]

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

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

From: Christopher Allan Webber
Subject: Re: [GMG-Devel] Kicking off "Kuneco": an atom and ostatus library for python
Date: Fri, 30 Dec 2011 14:44:24 -0600
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.92 (gnu/linux)

We had a chat on etherpad planning this out:

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


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

 - XRD generation
   - Example XRDs, currently Jinja2 templates
 - 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 
   - We can use inconexo's start of the lxml atom feed generator (borrowed from 

 - 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="",
...   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)?

reply via email to

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