[wsf-c-dev] Re: [] XMPP server side transport

[Sanjaya Karunasena]

What if think about this like this. A transport is an abstract entity which is 
been used by the server and the client both to send messages to each other.

With that, HTTPTranport is a Transport, TCPTransport is a Transport, 
XMPPTransport is a Transport.

So now the problem is pushed down to a level where we only need to worry about 
delivering a message from A to B. HTTP can do that, TCP can do that, XMPP can 
do that too.

When I want to chat with some one I have mention the jabber ID of that 
individual so that jabber can find the end point to deliver the message, like 
in HTTP we have to tell an URL or in TCP IP:PORT.

So then the question is how much do we have of such a XMPP transport at this 
point?

Does this make sense with the current Axis-C design?

Sanjaya

On Thursday 05 April 2007 10:14, Asankha C. Perera wrote:
> Samisa
>
> As far as I know Ishan had already thought through most of these issues
> when he developed the XMPP transport support to Axis2-C that we already
> have. Also the XMPP server to be used *will* be the one being developed
> by Jabber for ML with kerberos support and we will have to stick to its
> API's and these may have some variations from jabberd. I do not quite
> understand the current discussion on the XMPP implementation.. and why
> we are talking about things like dispatching at this point in time..  I
> will talk with Sanjaya and you on this.
>
> asankha
>
> Samisa Abeysinghe wrote:
> > I was Googling a bit to understand and figure out how to support XMPP
> > server side transport.
> > Here are some thoughts.
> >
> > First, I was initially under the impression that with XMPP server side
> > transport, a service would be a 'chat room'. However I have to change my
> > mind, because in the context of Axis2 architecture, a service is an
> > implementation of some processing with XML as input and XML as output in
> > AXIOM format. Hence with an XMPP server, we have to have a mechanism to
> > 'dispatch' an incoming request to a service that implements the
> > svc_skeleton API. Hence the key problem that we have to solve is:
> >         How can we dispatch (that is identify the service and operation)
> > an incoming request to our service? I hope we can use the same
> > dispatching mechanisms that we have in the Axis2 engine; however we have
> > to figure out how to interface that with the XMPP server API
> >
> > Jabber has a concept of "components". Some Jabber components can be
> > found in [1] and [2]
> > [3] defines protocol for external components. In my understanding, what
> > we need is an internal component. [3] mentions internal components, but
> > there does not seem to be a formal spec on that. Basically we have to
> > use the internal API of the server we are going to use. I also found JCR
> > [4]. " The Jabber Component Runtime *JCR* is the first attempt at making
> > "C" language components built for the *jabberd 1.4* code base able to
> > run as standalone processes". Standalone process sounds appealing as
> > that would solve our dispatching problems - we could run simple axis
> > server and interface it to XMPP server. We may have to do a POC and see
> > if we can use JCR with Axis2/C.
> >
> > Obviously this area needs some research work - so we need someone to
> > play around with these libs.
> >
> > Thanks,
> > Samisa...
> >
> > [1] http://www.jabberstudio.org/project/?cat=6
> > [2] http://www.jabber.org/software/components.shtml
> > [3] http://www.xmpp.org/extensions/xep-0114.html
> > [4] http://jabber.terrapin.com/JCR/
> >
> >
> > _______________________________________________
> >  mailing list
> > @lists.wso2.com
> > https://www-lk.wso2.com/cgi-bin/mailman/listinfo/
>
> _______________________________________________
> Wsf-c-dev mailing list
> Wsf-c-dev at wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/wsf-c-dev