we're working on similar types of issues and my take on it this... jabber
isn't an "application server" itself. it facilitates the routing of
messages to the appropriate destination - normally a human for chat. of
course the destination can be an "agent" or a transport with
business/application logic coded for a purpose which returns some data or
whatever. an "agent" could be a stock watcher, a "weather man", a news
grabber, data mine - the list is endless. you can write an "agent" in
almost any language with all the cool tools the dev guys have done -
Net::Jabber, JabberCOM, JabberBeans, etc... i'm partial to JabberBeans
'cause we do a lot of Java programming. then again, as "JAM" develops,
jabber could become more "application server"-ish.
not sure if that's the sorta explanation you're looking for, but i hope it
helps.
and if i'm wrong or off base in any way, someone let me know! ;-)
-wasted
On Wed, 9 May 2001, Gerard BUNEL wrote:
> Not exactly if my understanding of jabber protocol is correct.
> I beleive that the Jabber server acts simply as a router for messages whose
>destination is another server.
> But in my case, the Jabber user is also an Application Server user. So I try to not
>constraint the user to log twice for example
> I also want that some data already managed by the Application Server could be used
>as Jabber user's Data (vCard, Rosters, etc...).
>
> My first starting point seems to be XDB module. If my understanding is correct I
>should have to patch or replace the default
> xdb_file so that all persistent data could be completely managed by the Application
>Server.
>
> But, in that case, what about authentication data for example. Should they really be
>retreived from the Application Server.
_______________________________________________
jdev mailing list
[EMAIL PROTECTED]
http://mailman.jabber.org/listinfo/jdev
