This could even be taken a step further, beyond brute force hacking into proprietary IM networks...
- calendaring, document management, and other mics end user apps... - removal of any storage constraints imposed by the jabberd - user control of features installed Jabber suffers from central management... its distributed like email, but a central server still exists that is managed by an admin. This constrains the users to what the admin implements on the server. By using jabberd on localhost, it moves under the user's control and becomes more p2p-ish... Granted this is not a problem now, but what happens when there are so many protocol extensions that it becomes impossible for admins to accomodate all the user's potential needs? What about a chess/game extension that is seen as needless on the main jabberd, but the protocol requires a jabberd to function? ... By turning the public JID into a bridge to the localhost jabberd, the possibilities become a bit less constrained than what they are now. Obviously this won't work on a cell phone, but thats what the 'valid' JID is for. On Fri, 2002-03-08 at 02:08, James Widman wrote: > /me nods to the three previous replies. > > The concept of null clients also gets raised during conversations like > this. That's a nice idea too, but not really necessary. > > This is all you have to do: > > 1) If jabberd and the transports you want aren't known to work on your > platform, port them. > 2) Configure jabberd so that the server's host name is localhost, and > transports are running at aim.localhost, msn.localhost, etc. > (I tested this part out and it works for me; contrary to the *current* > server howto, you don't need a Fully Qualified Domain Name to get > transport services like aim-t and msn-t working; you just need the > client to be on the same machine as the server if it's not an FQDN). > 3) Use your client to log into localhost and register with the > transports from there. > > The drawback here is that you@localhost cannot send messages to > [EMAIL PROTECTED] However, one feature that's been requested for clients > is the ability to be logged into multiple jabber accounts > simultaneously. As time goes on, this will probably become a pretty > common feature, especially as jabber becomes more popular and more > people request it (actually, if it's ok with Julian, and if enough > people email me in support of it, I'd be happy to work this into > Gabber). If and when it becomes a common feature, it could make a lot > of sense to put together a jabberd package which is optimized for use by > a small number of users and comes with the most popular inter-IM system > transports. Would that help to ease the transition for end users? > > There's only one problem I can spot with a configuration like this: > the roster info for the localhost account will not follow you around > from one device to another. The user would have to manually do an > export/import. But there might be a clean way around this (if we're > going to have multiple accounts managed by one client, we might want a > clean way to store roster info on what the user designates as a > "primary" account anyway -- but *please* correct me if I'm wrong). > > --James > > _______________________________________________ > jdev mailing list > [EMAIL PROTECTED] > http://mailman.jabber.org/listinfo/jdev _______________________________________________ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
