[Members] XMPP Library Working Group
richard at dobson-i.net
Mon Dec 20 03:47:33 CST 2004
> Imagine the following situation: a user want's to write an
> application that does only a very limited thing - for example a
> weather agent that informs you with weather information.
> At the moment a developer would have to write not only the code to
> request and show weather information but also would have to write
> much (even more) code to register and setup a complete XMPP account
> for this. This might als require user interaction to register and
> setup the account.
If the developer doesnt want to write this code why cant they just use one
of the existing libraries to avoid this?, most of the more simplified code
libraries support simple methods of account registration (if indeed they
even need to register an account), also as far as accounts go for simple
things such as a weather information system that will be hiding the jabber
system it interfaces with completely from the user there is no need for it
to even login to an account the pc's owner owns, it could just login with a
generic account that the developer defines just like pubsub.com's sidebar,
either that or you could do the next thing I suggest below and simply
retrieve the account info for the user from a standardised location.
> If there would be a way to acquire user's default XMPP account from
> system (for example from a system service that would also take care
> about resource name conflicts) it would mean less work for the
> developer and the user.
Wouldnt it just be far easier to just standardise/agree the storage location
and format of XMPP account information for each OS?
Do you have any other significant benefits other than these?
For me at least the complexity of implementing the system you suggest just
doesnt seem worth it im afraid, the only way (for windows at least) you
would really be able to make this system simple for developers would be to
convice microsoft to include this as a feature built into windows (which is
something I find highly unlikely), otherwise without this the developer will
need to include a method of installing and setting up your system along with
their own application as they cannot guarantee that end users will already
have your system installed and setup, IMO this seems to make things far more
complex for the developer compared to them just using one of the existing
code libraries. How would you overcome this problem? Another problem is that
your system introduces a single point of failure.
Overall I am finding it hard to think of any benefits over and beyond what
you suggested above and can think of more disadvantages which is never a
good situation when trying to justify something, the problems that I can
immediately think of I will list below, these are things you really need to
address in your proposals to everyones satisfaction without making things
more complex than the developer just using an existing code library, or
making things any more complex for the end user:
1) Single point of failure
2) Requirement for developers to bundle the system along with their own
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
4) Upgrading existing installations of the system when applications
requiring a newer version are installed.
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.
6) Developers will likely have to write jabber xml processing code anyway
with your system if they want to take full advantage of jabber.
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
More information about the Members