Month: October 2005

Hey Lucas, and the gegls from outer space, free the fish! :-P

That said, I launch a virtual petition titled: Don’t kill wanda!

By the way, check out the Nokia ordering page for ordering your Nokia 770.

A few weeks ago I discussed with Peter Saint-Andre the problem that there were no best practises specified for so called “offline messaging” with the XMPP standard. While Instant Messaging is one application that implements the XMPP protocol (as further described in XMPP-IM) and while for “Instant Messaging” the delivery of a message to a person who isn’t available at the time message is being sent isn’t (always) critical, other applications that implement the XMPP standard might or might not have reasons to mark this aspect of the standard as an important one.

Since as far as I know all Jabber service implementations support this “offline messaging”-feature, there was a need for specifying the best practises.

So Peter specified it in JEP-0160: Best Practices for handling offline messages.

I’d like to thank Peter Saint-Andre for making this Jabber Enhancement Proposal.

We are planning to use XMPP for applications like distributed package management. We’d like to signal clients when they should update themselves. And we’d like to make sure clients will get that message when they rejoin the network in case of being offline or unavailable (mobile devices and in case a desktop on a corporate network was shut down). It’s also interesting for the concept of distributed personal preference management or distributed desktop configuration. Why reinvent the wheel if you have both good and existing/tested service implementations and a suitable standard for this? XMPP fits the requirement.

This, this and that it’s very unfinished. That’s all I’m saying today.

Interesting …

It looks like Robert Staudinger imported GtkMozEdit in the GNOME cvs repository.

Perhaps it’s a bit premature to already mention it. And I’m not making any promises. Nevertheless is my Sauron eye fixed on trying to replace the GtkHTML editor Bonobo component with GtkMozEmbed.

Some information about the attempt to do this with our poor Evolution can be found here. To be more specific you can make a GtkMozEmbed component editable using this API. That API, however, of course doesn’t mean that this is/will be a flat road without issues and problems.

For example one issue is that the current state of the EMsgComposer code is a little bit tight to the Bonobo way of working. Another issue is that there’s a lot “commands” to support (like, “insert html”, “set bold”, “undo”, “redo”). Most are also supported by the nsICommandManager. Some are not.

So I started with making sure that other parts of the Evolution code don’t try to tamper with private fields and members of the EMsgComposer. Why? Well, if we’re sure no other Evolution developer used something other than the API as agreed in e-msg-composer.h, then a programmer can more securely alter the internals of the implementation (e-msg-composer.c).

You can find the result of that first step (data hiding) here. As usual, if you want to help. Contact me, or you know .. help (give me tips, guidance, whatever). Note that I don’t even know whether or not the Evolution maintainers like this idea. So this blog entry doesn’t mean that in a few weeks you’ll have a slick Gecko HTML editor component for typing your E-mails in Evolution.