[Members] XMPP Library Working Group

johannes.wagener at gmx.net johannes.wagener at gmx.net
Mon Dec 20 09:29:25 CST 2004


On 20 Dec 2004 at 9:47, Richard Dobson wrote:

> 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.

> 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.

> 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...

> 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!

> 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... 

> 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...

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());

I really welcome your comments, please post them in future in the 
wiki:

http://relayed.net/wiki

regads,
Johannes


More information about the Members mailing list