[Members] XMPP Library Working Group

Richard Dobson richard at dobson-i.net
Tue Dec 21 03:42:22 CST 2004

>> 1) Single point of failure
> That's always the case if you store global accesible information.
> Whatever it's the same case when you click a mailto: link in
> webbrowser and user's default email client pops up. Anyway such a
> thing is worth the risk having not setup an email client.

Urm im confused with this analogy, mailto is something entirely different
from having a system service that interacts with other applications on the
system mailto doesnt strictly create a single point of failure as the email
client does not necessarily have to be running to accept mailto commands,
also even if the email client stops working other programs will not be
relying on it in order to function, whereas in your proposal if that system
service fails non of the programs that use it will be able to use jabber
thats where the single point of failure comes in.

>> 2) Requirement for developers to bundle the system along with their own
>> applications
> Depending on the solution we might choose this would be the case.
> But it was the same with JabberCOM.

No it wouldnt if I am understanding your system service spec properly, with
jabbercom you can easily just distribute the dll with your app and register
it with one command and never need to worry about it already being
installed, whereas developers will need much more complicated code most
likely to detect/install/upgrade your system if its already there, otherwise
they will risk breaking the system service, COM objects are something very
different from a system service/client daemon (XCD).

>> 3) Compatibility problems between versions, i.e. like with
>> windows dll's how do you prevent breaking older applications when you
>> update the system to a newer version.
> Again depending on the solution we would provide. In case we would
> really use a simple service/daemon it could return xml:
> <account>
> <server>jabber.org</server>
> <port>5222</port>
> <username>edrin</username>
> <pwd>xyz</pwd>
> <proxy_server>proxy.blah.com</proxy_server>
> <proxy_port>8080</proxy_port>
> <proxy_username>edrin</proxy_username>
> <proxy_pwd>god</proxy_pwd>
> <connectiontype>0</connectiontype>
> </account>
> defined in a JEP. Account information xml wont have to change much in
> future... daemon's tcp port neither...

But whats the point, this has no benefits that I can see over just
standardising a location to store account information for each OS, i.e.
registry etc.

>> 4) Upgrading existing installations
>> of the system when applications requiring a newer version are
>> installed.
> Dunno, maybe we can add an autoupdate thing. In exodzus this is
> working very well!

Auto updating a system service and auto updating an application are two very
different propositions, this also means a whole raft of logistical concerns
like setting up a website that will be able to handle the load of thousands
(maybe millions if this were successful) of machines trying to auto update,
there is also the problem of permissions for system services and restarting
and registering them etc, surficed to say auto updating system services is
"a whole different kettle of fish" to auto updating applications.

>> 5) Security. Not just any application on the users system should be being
>> allowed to login using the users account details, just allowing any
>> application to access the system may mean that trojan/spam/spyware/virus
>> software may start sending out spam jabber messages using a users
>> legitimate account details very easily just like the problems outlook
>> users have today with email borne viruses.
> As another responder just said: If the system ins compromised we
> can't do anything against it. That someone would write a spambot
> using this system requires the thing to be widely used...

Isnt your goal to have this widely used?? And in any case you cant say
security is not important, certainly where you proposing a system where it
makes it orders of magnetude more easier for people to create these spambots
than it currently would be, the easier you make it the more likely it will
be that someone will create these spambots, just look at all the problems
microsoft is having with the scripting built into their office applications.

>> 6) Developers will likely have
>> to write jabber xml processing code anyway with your system if they want
>> to take full advantage of jabber.
> Yes, sure. But they wont have to do interacting GUI to setup,
> register and manage XMPP accounts. As a developer I know that this is
> consuming much time and must be prepared for many error cases...
> In fact for a simple tray weather agent or let's say mail
> notification or sms application it's more then 50 % of the work...

But as I have shown giving pubsub.com as an example for these simple little
applications there is no need for them to be setup to login using the users
real details or for them to be able to register accounts, they can just
login using generic details just like the pubsub.com sidebar does. Also I
would question how much time creating the code you speak of really takes to
create (im a developer too and have created such applications) and the time
it takes to code (which imo when I have done it in the past was negligable)
does not justify creating a system such as you propose, why cant they just
use code libraries instead if they dont want to create this code in their
own app?

> 7) As has been said a single API will
>> not be useful to a lot of people because it might not fit in with their
>> programming language/program structure.
> Yes, I am discussing a way how to make this interact with existing
> jabber libraries...
> Like library developers would add a function:
> GetDefaultJabberAccount()
> myXmppObject->CreateJabberConnection(GetDefaultJabberAccount());

Isnt it better to just standardise a location to store account information
for each OS, not have any of this XCD stuff as the complexity of it is just
not worth it, and just let the code library developers add support for
retrieving the account information from the common storage location
themselves in a way that matches their code structure rather than you trying
to dictate to them what their API should look like.

There is no point you trying to standardise the API calls as these will vary
depending on how the code libraries are structured and thus anything you
define will not be relevant for everyone and so will be redundant, you will
not succeed trying to standardise the API calls but there is no reason you
cannot succeed in standardising a common location and format to store jabber
account information for each OS, this is where IMO you will be best
expending your effort.


More information about the Members mailing list