tcharron at ductape.net
Fri Apr 20 08:34:42 CDT 2001
From: Greg Hookey <ghookey at elegant.ca>
To: info at jabber.org <info at jabber.org>
Cc: jdev at jabber.org <jdev at jabber.org>
Date: Thursday, April 19, 2001 9:06 PM
Subject: [JDEV] why?
> I've been looking over your IM system for a while now and I am wondering
>why you have made certain design decisions.
I have to be completely honest in saying this, and I'm not trying to
insult you, but either you where not looking all that deep, or not for all
>1) XML....it's new...it's usefull in some situations, but not this one.
> Why did you choose it. It's makes now sense. You made your
> files way too complex. You've used it as your user database in which a
> file per user is in no fashion scalable and makes your IM system
> rediculously slow. XML has no place here. Especially in a file per user
Err.. Umm.. I understand what your saying here, but refer to my above
statement. The basic xdb storage is called basic for a reason. It is the
simple, 'This will work anywhere'. Sure, it doesn't scale. Of course it
doesn't scale, it's the basic storage module.. 8) I also believe that when
you state using XML you are refering to the configuration and storage areas,
and NOT the use of XML over the wire for the transport.
>2) Why in your new CVS version, try to solve this problem by substituting
> a relation database for a file system. You must realize that this idea
> is plain rediculous and does not solve the problem of parsing an XML file
> per user when this should be realistically a database of such information.
This is a halfway step. I have to tend to agree with you that storing XML
in the database is kinda silly. But I cannot agree with you regarding the
parsing of XML. If you look at the alternatives, the parsing of raw XML is
no more intensive then a complex tablescan in a relational database. XML is
not some 'Just released yesterday' technology anymore. I've been using it
for the last 2 years. 2 years in the computing industry is a *VERY* long
>I've considering using your product in several projects now and I have
>been deterred by these poor design/implementation decisions. A tip, just
>because a technology is out there doesn't necessarily mean that is is a
>solution for a problem. And again, XML doesn't fit the bill. I will
>to watch your progress and I wish you luck in the future. Without a better
>design, you are truly going to need it.
And while I do not belive that this was meant to be a troll, you must see
that the messages underlying tones made it sound like one. Your most likely
not going to get very much response to this. I've been in/out/lurking with
Jabber for nearly 3 years now.. (Woah.. It's been that long??). It's
emerged quite a bit, and will continue to do so. There are design and
implementation limitations in the system. All systems do. I have to
disagree with the use of XML as being one of those limitation. We now have
the backing of Microsoft, IBM, Lucent, Cisco, and nearly every other company
out there today. It is no longer a 'fad' technology. It is a system
neuteral technology. Currently, I'm using VoiceXML to communicate with a
telco, Quest communications specifically, for non premise based IVR systems.
XML provides one thing that nothing else has. A standardized way to
represent data. In the past, there where two thing to worry about. The
data format, and the data content. Now we just have to worry about the
Are there better technologies out there? Sure there are. Could a given
protocol / format be used in place on XML? Yep. But could those protocols
transparently ride *ANY* data within their format, without any modifications
of the server, or even end clients? Not to many.
Of course, then we can talk about Jabber itself. WHO SAYS Jabber as a
system has to use XML for any part. If you don't like it, *REPLACE IT*.
Your a software engineer, talking about design and implementation. You can
change any peice of it you wish! Want xdb to be storing data in a pure
relation database, using a mapping scheme? DO IT! Heck, Jer even started
writing alot of that a good while back with the mod_mysql module. The
manhour cost of modifying a peice to fit your needs is a fraction what it
would take to implement your own solution.
*scurries back into his little hole before anyone notices he came out and
actually said something..*
More information about the JDev