ralphm's blog

XTech Report #1

I'm at XTech now. I have this neat little 1-star hotel, which is conveniently located for all my traveling. This morning key notes were pretty interesting, and following those I attended a talk on Creative Commons in Science, i.e. non-computer science. Working on a University, that was a real eye-opener.

Currently, I'm in Room M, attending a talk on XUL. The room is packed, and I'm actually sitting on the floor, just behind the beamer. I'll put all my photos here.

Posted at 11:54 by ralphm #.

NLUUG and XTech Conferences

This week is going to be a busy one. I will be speaking at two conferences, naturally about Jabber.

I've written about one of these conferences before. On Thursday 26 May, the Dutch Unix User Group (NLUUG), will hold its spring conference in Ede, The Netherlands. The topic is E-mail and Beyond, and my talk is an introduction into Jabber and how it might be used to replace current E-mail standards, while solving a number of problems currently found in the E-mail landscape. I will also touch the Beyond aspect of Jabber.

The other conference is XTech 2005, a three-day event held in Amsterdam. Coincidently, the tagline of this event is XML, the Web and Beyond. Lot's of Beyond going on these days. This conference takes place on Wednesday 25 through Friday 27 May, which overlaps the NLUUG conference. This is a pity, but fortunately, my presentation will be on Friday. I will be filling in for Peter Saint-Andre, who was unable to attend. Our paper, for which he deserves most credit, can be found here.

The range of topics of both conferences really matches quite nicely with my interests. So, I'm really excited to get to meet a lot of smart people. I've booked some 1-star hotel and will be traveling quite a bit this week. I also need to be in Amsterdam for my work on Tuesday, and will most likely stop by the co-location facility to monitor the upgrade of our machine mag.ik.nu that evening, hopefully to be concluded by a informal get-together before XTech takes off.

Posted at 22:18 by ralphm #.

Too late

On second thought, I'm sorry sneakin. That title has already been taken. But you could make it one day. This should get you in the right direction.

Posted at 21:33 by ralphm #.

The Mysterious Council

There has been quite a bit of discussion on the Jabber Software Foundation Members mailinglist about the role and tasks of members of the JSF, which then evolved into a discussion about JSF approved software and/or Jabber/XMPP compliance certification. So far, none of the Council members have commented in that discussion, but now sneakin makes a comment about the alleged existence of a inner circle in the community, and that being the Jabber Council. On top of that he claims that its workings [...] are quite a mystery.

I'm sorry, but I am offended by these statements. First of all, I don't believe there is such a thing as an inner circle in the way suggested. Yes, there are people who have been around for a long time, have served on teams or councils, have authored many JEPs or otherwise contributed in a more-than-average way to our community. They apparently earned the respect of others in our community and that's a good thing. With respect comes influence, I guess, but what's not true is that they have a special status of some kind. I believe that anyone in this community, that contributes in any significant way, will also earn the same respect and influence. Maybe some of these influentials are more vocal or outspoken. Is that bad? Maybe they are also hard-headed, but at the same time reasonable enough to bend as a result of good counter arguments.

When I applied for the Jabber Council last year, I got unanimously voted in, and I was flattered by that fact. But does that mean I now belong to the inner circle? I hope people voted me in because I made a contribution in discussing protocols, and that my views alligned with the membership of the JSF, or at least enough to trust me enough to represent them in the Council.

About the council: we are not mysterious. Anyone getting enough votes can get in. You get votes by being visible and a credible applicant for the job at hand. A good mission statement helps. Our workings are transparent. We discuss pretty often (once in two or three weeks) in the council@conference.jabber.org chat room (logs) that is open to everyone albeit voice-less. Also, there is the Council mailing list, that also provides archives. The meetings are always announced on that mailinglist, and everything we do is through these two channels. Oh, and of course there is the standards-jig mailinglist for general protocol discussions and council announcements. No secret stuff going on behind doors. By the way, this information can be found on this handy page from the frontpage of the JSF site.

Finally, I'm glad that non-council-members are discussing things like certification, and hope something good will come out of that, eventually. I'll weigh in when I have sorted out my opinion on the subject.

Posted at 12:40 by ralphm #.

My Thesis Online

More than a year ago, I finished my Master's thesis. Last tuesday, the DARE programme offically launched their website. The DARE programme provides free access to the complete academic research output of all Dutch universities, and as a result my thesis has also been made available. Initially, this was a PDF of a scan of a print of a scan of a print, but I had it replaced with the original PDF, giving you the full experience.

Posted at 15:45 by ralphm #.

Managing Profiles

In a continuing effort, stpeter makes some observations about managing profile data in Jabber. More specifically, how to do that using our publish-subscribe extention. Here are my thoughts.

What if you posted your profile information to just one node, having the fields distributed among various node items? Subscribers could select the desired fields by using subscription configuration, resulting in a content-based subscription. A subscriber would then only get notifications for those fields, and in the beginning fetch the complete view of the profile by just retrieving all node items (for his subscription).

What about access control? Well, you could base the access control on the supplied selection of fields. The authorization form for the subscription could include this information as a custom field (starting with x- as specified in Field Standardization for Data Forms or by registering it with the Jabber Registrar). After initial configuration, a subscriber may not change this configuration option (it would not show up when trying to reconfigure the subscription later on). Not sending a configuration form along with the initial subscription request would imply wanting access to all fields. This is partly because so-called unconfigured subscriptions have already passed the authorization phase.

To comment on general vs. application specific pubsub services, I suppose that many applications would need some customization in the service implementation. I think this is at least true for any content-based pubsub service (because you need to have a way to query the content). On the other hand, for simpler applications like extended presence, generic services should be sufficient.

Another possibility is pubsub applications that use only parts of the protocol. For example, one could have a service that does allow subscribing to nodes and receiving notifications, but denies the creation of new nodes or publishing via the pubsub protocol. Instead, a notification could be the result of some out-of-band event: a change in internal state or data received via another protocol (XMLRPC, e-mail, etc.). Or, my idea of how Mimír should be re-implemented as a customized pubsub service that allows plain-text notifications based on presence, and has side effects in the form of a personal news page.

Posted at 15:04 by ralphm #.