It will open the item (tweet or similar) in the forthcoming Mauku 2.0 Application. That way you can see the details of the item, reply to it, forward (retweet) it, browse the history etc. The Mauku Widget is simple way to check the latest items, but the actual application is to the way to do the rest.

(Maybe there should be a separate thread for Mauku Widget.

Microfeed should be possible to just recompile in Diablo also, but modifying Mauku version 0.x or backporting the new Mauku 2.0 Application to Diablo is somehow bigger task. I am focusing on Fremantle version now, but maybe later I have time to do something with the legacy platforms too.

However, Mauku and Microfeed are open source projects, so, if someone has time and skills, she/he could join in and make this happen sooner. Should I announce that "open (source) positions available: Mauku legacy maintainer"?

I just alerted the Mojito maintainer as Microfeed would probably be useful there too. More code and service sharing between Maemo and Moblin can't be bad

Version 0.2 of the implemention is out now. The API has been changed a bit, and is still expected to be changed before version 1.0 is out. There are also other enhancements and bug fixes done during the development of Mauku 2.0 application for Fremantle.

http://www.microfeed.org/

I have released version 0.3 last night. The API has been changed slightly again and internal implementation a lot. The aim has been stability. The development will focus on optimisations next.

http://www.microfeed.org/

Version 0.4 of the implementation of Microfeed is released. It introduces so called virtual feeds that make easy to implement comment tracking and channels for services supporting such functionality.

Mauku 2.0 beta 3 and Mauku Widget version 0.9.3 are based on this version of the library.

And yes, this is open source software project, released under GPL/LGPL (see COPYING file in the distribution).

The source code of the reference implementation of Microfeed is now hosted in Gitorius: http://gitorious.org/microfeed

The database backend is reimplemented from scratch. The library is not using Berkeley DB anymore. Thus, it is not required to use GPL license in some components, and the whole Microfeed library is released under LGPL now.

Nice but how to compile it? I need to write Python backend of it and after that support of microfeed in Gwibber

Good question, thanks for asking. Here are the basic steps:

• Fetch the source code
  
  Code:

         git clone git://gitorious.org/microfeed/libmicrofeed.git

• Enter the source code directory
  
  Code:

         cd libmicrofeed

• Generate the configure.sh script (autotools are required)
  
  Code:

         autoreconf --install

• Configure the package
  
  Code:

         ./configure --prefix=/usr

• Compile the source code
  
  Code:

         make

• Install the library
  
  Code:

         make install

• Leave the directory
  
  Code:

         cd ..

After that you need to compile and install also the microfeed-utils and the microfeed-providers-unstable packages. Just substitute the word libmicrofeed with those and perform the same steps.

I also wrote these instructions into a wiki page:

http://gitorious.org/microfeed/pages/Compiling

Nice! I discussed about the topic with Ryan in Maemo Summit. Microfeed and Gwibber could be a perfect match and benefit each other.

For Gwibber, it would be enough to either write a new implementation of libmicrofeed-subscriber from scratch in Python or just to make Python bindings for it. For starters at least. As microfeed is operating on top of D-Bus, the subscriber (client) part is fairly straightforward to implement.

See the specification (http://microfeed.org/specification/) and the source code of microfeed-subscriber module (http://gitorious.org/microfeed/libmi...eed-subscriber). Please note that the current version of the specification is a little out dated (new features introduced and others are fine tuned), so the reference implementation is formative for now. This will change of course before version 1.0.

If you want to implement new providers in Python, then it would be feasible to make Python bindings for the rest of the library (libmicrofeed-common and libmicrofeed-provider). Those contain over 10k LOC of logic (caching, for example).

Actually, it is too verbose to write a new provider for now. (See, for example, the current Twitter implementation: http://gitorious.org/microfeed/micro...master/twitter) There are many patterns that have to be copied (mostly as is) when implementing a new provider. I will further encapsulate common logic into the library itself, so the provider implementation should be more straightforward in the future.

Does the microfeed backend support encryption during authentication to service like Twitter or does it send authentication info in clear text?