Log in

No account? Create an account

Previous Entry | Next Entry


2005 Desktop Developers' Conference, Day 0

  • 19th Jul, 2005 at 8:58 AM

Attacking a power cord
Originally uploaded by sfllaw.

This kitten is doing what I contemplated doing sometime this morning. You see, I've been hacking UniConf to work with D-BUS, and the D-BUS on my laptop was not the same as my desktop at work. I spent most of last night pulling it back up to functioning. I now have working code that I should check back in.

I'm currently hacking Firefox to read its bookmarks out of UniConf. With any luck, this will work fine for our demonstration.

I'm very tired now, I hope I can make it through the talk. I suppose I should mention that yesterday's talks were pretty good, although sort of lacking in the integration theme. Sadly, that's not very predominant on the free desktop these days. Perhaps next year, we'll see more; especially if we manage to convince people that UniConf is a Good Thing.

P.S. I had some people over last night and made some peach and raspberry crumble. This went over quite well with the crowd. A bunch of people showed up, and Keith Packard brought a bottle of bourbon and a bottle of scotch. He has also promised me pie today. How great is that?


( 14 comments — Leave a comment )
19th Jul, 2005 14:14 (UTC)
Cute kitten!

Could you say a few words about the integration issue that you'd hoped to hear about? Do you mean cross-application integration?
19th Jul, 2005 16:34 (UTC)
I do mean cross-application integration.

What I'd like to see is more infrastructure work that allows applications to co-operate easily. Right now, DDC is full of presentations where people talk about their specific application, and very little else.

It's too bad, you know. Because that's a very slow way to improve the user experience.
19th Jul, 2005 15:31 (UTC)
Gah! You are thinking of linking WvStreams/UniConf into mozilla? That application already uses over 100mB of memory. While it would make a cute demo (updating your bookmarks from a remote computer using mutt), please, for the rest of us, don't.
19th Jul, 2005 16:32 (UTC)
I'm pretty sure that this is a good idea, only because I get to toss out a large source file in favour of a recursive iterator.

But you don't need to link in all of WvStreams/UniConf at all. You can just talk the UniConf protocol raw.
19th Jul, 2005 16:54 (UTC)
You get to toss an source/object file in favour of all of WvStreams; but you already knew that was a flawed argument.

Talking the raw UniConf protocol is a cheesy cop-out that throws away most of the 'Uni' features of UniConf. On top of that, the protocol described on OpenNit is so broken and poorly designed that it should not even be discussed as an alternative.

19th Jul, 2005 19:27 (UTC)
I think Simon was talking about the Uni-DBUS protocol (which is not yet documented on OpenNit).

That being said, the UniConf network protocol on OpenNit doesn't seem that horrible to me: it's just another simple, line based protocol in the grand tradition of SMTP, IMAP, etc. What do you hate about it, specifically?
19th Jul, 2005 19:58 (UTC)
It's funny you mention SMTP and IMAP, as they both have features that the UniConf protocol is/was lacking (tagged commands of IMAP, versioning and extensibility of both SMTP and IMAP).
19th Jul, 2005 21:57 (UTC)
Fair enough. It wouldn't be difficult at all to add these things though, so my question still stands.
19th Jul, 2005 22:16 (UTC)
I'd be curious too to know what he meant, as I don't disagree with your fundamental question, just pointing out a few things.

I'd be interested in a comparison with ACAP, myself.
20th Jul, 2005 06:06 (UTC)
The UniConf protocol has gender issues.

Take a well behaved, mostly boring protocol, POP3. It is completely state based; that is, if you send a POP3 server a LIST command, it will enter the list-outputting state; when finished it will return to the command-accepting state. This allows you to abuse the POP3 server retchmail-style since you know the layout of the server's state machine.

Now, say you want to do something similar to retchmail with the UniConf protocol. Open a connection, send:
GET ashley/phone
GET ashley/status

and wait for the expected reply:
ONEVAL {ha! you wish}
ONEVAL {in golly old England}

but somebody, somewhere is twiddling bits, so instead you get:
ONEVAL {ha! you wish}
NOTICE {melissa/reachablefactor} {low}
ONEVAL {in golly old England}

Oops. Now mind you, this is not insurmountable. However, instead of writing a quick in-and-out lets-talk-to-the-UniConf-server-raw client, you now need a client that does error checking and exception throwing from deep within its state machine. (And many people are too lazy to write that, so instead they end up with broken implementations)

A better solution would be to either poll for NOTICEs or embrace a protocol with less state similar to IMAP.

20th Jul, 2005 06:08 (UTC)
See here:
for a slightly different rant.
21st Jul, 2005 13:39 (UTC)
A better solution would be to either poll for NOTICEs or embrace a protocol with less state similar to IMAP.

For this, you should get on D-BUS.

I'd point you to our public subversion repository and the unity module, but that's not up and running right now.
21st Jul, 2005 15:27 (UTC)
Yes, I would wholly support undocumenting the 'UniConf protocol' and forgetting that it ever existed.
(Deleted comment)
( 14 comments — Leave a comment )