[Geyser] Merge/Cooperation with Mumbles Project

[Peter Savage]

On 06/11/2007, dot_j <dot_j at mumbles-project.org> wrote:
>
> Hi all,
>
> I wanted to open a discussion about a merge/cooperation with my
> project (http://www.mumbles-project.org). I missed some early
> discussions between VCSFrenzy & Specto about the creation of this
> project, but just saw the update to/creation of Geyser and thought I'd
> toss in what I can here. I think the various active projects in the
> notification realm all share such similar goals where it makes sense
> to work together and hopefully come up with a unified framework. I
> especially noticed that a few main goals  of Geyser overlap with what
> I have already (at least partially) implemented and would like to add
> going forward. A few things to this point:


Great to have you on the mailing list dot_j.  Looking forward to working
with you.

* Plugins - Currently, mumbles is input side only, but I would really
> like to see output plugins. I use python eggs for the plugins as I
> think they are easiest to deploy - has there been any discussion about
> plugin packaging for Geyser?


Currently there has been no discussion about the distribution of
input/output plugins, though I did raise the point of having them work
similar to the eclipse framework, where you can download them from the net
and it'll inform you if there are updates to your plugins, like firefox.  I
think this would be the ultimate system.  But adding complexity not only
means that the coding time will take longer, but the planning stage too.

* DBus driven - Mumbles plugins define a signal to which they listen
> and when the signal is caught mumbles sends that signal information to
> the plugin where it processes the information it needs and hands it
> off to the notification class (or, in the future, a notification
> plugin). I took this approach as it greatly reduced what the plugin
> had to do. Pidgin, Rhythmbox, etc. already send out the info I want,
> so I just needed a way to relay that information to my notification
> system. From what I've seen, you're thinking of a similar approach -
> how are you planning on handling plugins for applications that do not
> send to the DBus? My approach has been to write DBus plugins for what
> I can (Amarok, Thunderbird, Firefox). But I'm a little torn on how to
> handle something like and RSS feed, or VCS notifications in your case.
> I tend to think it's best to have separate applications for these
> tasks that send signals to the DBus. That way, mumbles et al can pick
> those signals up, but so can anything else. I've tended to shy away
> from building plugins that do more than listen for other application
> signals to stress reusability and to focus on getting applications to
> use the DBus. Any thoughts here?


Well, none of the plugins for VCS-Frenzy were dbus related.   They were
threaded python processes.  It'd be awesome to see if we could integrate
your plugins into the input side of Geyser ;)

I guess this issue ties into the plugin conversation. I've seen some
> comments in threads here already talking about the possibility of
> plugins in various languages - it seems to me that if the plugins deal
> with DBus signals that they don't need to be. Simple signal matching
> to callback functions (like those in mumbles plugins) can be written
> easliy & quickly and packaged nicely in an egg - then applications are
> responsible for sending dbus signals.


This is the general idea, that plugins written in other languages will use
dbus to communicate, however we would probably work using exported methods
rather than signals, for security reasons.


Like I said above, I'm torn on
> this issue as it requires DBus support in applications or standalone
> applications that don't do much besides send DBus signals (an RSS
> notification is a good example of this) - but I do think other
> applications outside of a notification framework could make use of
> these type of applications (Awn is a good example of this).
>
> Does it make sense to have a 3rd level of plugins that are at a higher
> level to do some of these things? A few quick examples to help
> illustrate what I'm thinking:
>
> * An RSS app that checks for feed updates and sends a DBus signal.
> This could be picked up by the notification system, but also by a
> desktop widget, a panel application, a taksbar, etc.


Well in this case what would happen is that the RSS input, would be tied to
a DBus plugin, and then other applications would have to be told to listen
on a particular bus, to pick up the data.  Hopefully if the word got out,
apps that could pickup data like that, would start being written with Geyser
input streams

* Similarly, something like VCSFrenzy. Same thing here - if that just
> sends a DBus signal, anything can look for it. So while you might see
> instant popup notifications of a commit a desktop widget can show you
> a list of the 10 most recent commits. And neither rely on having the
> other around (though in this case it does seem to make sense to have a
> shared log of these notifications - but is that on the app, or on the
> notification framework? It seems to me that it's the app should be
> responsible for saving that information so it's resuable, no?


Yes indeed, we have discussed this briefly, but are still deciding on how
this will work.  It's quite possible that the output plugin can query the
notification for a log of notifications, however, this would require some 2
way communication which would break the whole "output" plugin guise.  There
is nothing to stop us writing output plugins that are daemons though.  I
gave an example the other day of an output plugin that was a jabber client,
and could accept inputs to give me information.

And from what I've seen, this is the bit that VCSFrenzy and Specto
> already do really well (among other things of course). If the focus is
> shifted away from the notification aspect and these apps just send
> DBus signals it seems to open up the number of things you can do with
> that data. As part of (or as a seperate piece that plays nicely with)
> a unified notification system, I think it would be very cool to have a
> set of these utility applications that are available to any part of
> the desktop - any thoughts on this?


It's the overall plan, we're still thrashing out the main process method at
the moment, but we're getting closer and closer everyday.  Watch out for a
new email coming about extending Geyser, it'll blow your mind....well it did
mine.

I like to think I have already worked out a lot of the issues with
> things like the DBus and egg plugins that I would imagine will come up
> in development here, so I'm wondering if the approach isn't similar
> enough were we could extend upon what mumbles already is and get right
> down to business on the other goals. Please do take a look at the
> mumbles code - as I was learning a lot on the way, I'm sure a lot can
> be cleaned up/improved upon, but it seems like Geyser is so similar to
> mumbles that it makes sense to work together here. I'm open for
> comments/discussion - hopefully we can come up with a standard,
> unified system. I know I sure want something bigger.


The bigger thing we have in mind is just awesome.  I'm just about to start
composing a post on it now.  I would love together and I'm keen, though I
will look at other projects, to start Geyser from scratch.  Plugins are a
slightly different matter, but the main core will be written from scratch,
and well thought out.

Thanks,
> dot_j


No no, Thank you !!
Can't wait to hear more.

_______________________________________________
> Geyser mailing list
> Geyser at progbox.co.uk
> http://progbox.co.uk/mailman/listinfo/geyser_progbox.co.uk
>



-- 
Pete Savage - cbx33::silentk
wiki.ubuntu.com/PeteSavage
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://progbox.co.uk/pipermail/geyser_progbox.co.uk/attachments/20071106/178b822a/attachment-0003.html