Wednesday, 25 May 2005
Live from the floor...
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.
Sunday, 22 May 2005
This week is going to be a busy one. I will be speaking at two
conferences, naturally about Jabber.
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
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
The other conference is XTech 2005, a
three-day event held in Amsterdam. Coincidently, the tagline of this
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.
Friday, 13 May 2005
Even more mystery...
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.
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
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
Thursday, 12 May 2005
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.
Wednesday, 11 May 2005
Who knows what about me?
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
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
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
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