You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mina.apache.org by Bernd Fondermann <be...@googlemail.com> on 2010/04/18 21:33:04 UTC
Implement WebSockets/BOSH for XMPP AJAX clients
On Sat, Apr 17, 2010 at 23:08, Bogdan Pistol (JIRA) <ji...@apache.org> wrote:
>
> [ https://issues.apache.org/jira/browse/VYSPER-189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12858184#action_12858184 ]
>
> Bogdan Pistol commented on VYSPER-189:
> --------------------------------------
>
> The right place for a discussion is on jira or on the mailing list?
Depends. At least for more general discussions, the mailing list is better.
> In my view the decoder could be like:
>
> raw bytes --> AsyncWeb decoder --> XML extraction --> stanza creation --> Bosh IoHandler
>
> and the encoder:
>
> stanza --> XML serialization --> AsyncWeb encoder --> raw bytes
>
> The Bosh IoHandler could work with a Bosh StanzaProcessor that would eventually process with some Bosh StanzaHandlers the stanzas and then it will send the processed (as defined by XEP-0206) stanzas to the XMPP StanzaProcessor.
>
> What do you think?
I don't fully understand that plan.
Especially the term 'Session' is missing here for me. Client-side
stanzas are processed in the context of a session.
I didn't check with AsyncWeb, but I guess the patch copies its source
code over to Vysper? I don't see a point in doing so. Why not create a
dependency on the AsyncWeb library?
Say you have a webserver already running on your vysper.org machine.
Then you'd probably want that process to handle the HTTP-side of BOSH,
too. So we need two basic modes of operation - in-process and separate
processes.
You draw above: "stanza creation --> Bosh IoHandler"
I don't understand that. Do you mean SessionContext?
I'd like us to evaluate Jetty, too. It's properly maintained and it
implements the most recent standards in async web processing. WDYT?
Bernd
Re: Implement WebSockets/BOSH for XMPP AJAX clients
Posted by Bogdan Ciprian Pistol <bo...@gmail.com>.
On Sun, Apr 18, 2010 at 10:33 PM, Bernd Fondermann
<be...@googlemail.com> wrote:
> I don't fully understand that plan.
> Especially the term 'Session' is missing here for me. Client-side
> stanzas are processed in the context of a session.
The session would give the session context for the stanza processor as
it's done now in Vysper (stored as an IoSession attribute).
> I didn't check with AsyncWeb, but I guess the patch copies its source
> code over to Vysper? I don't see a point in doing so. Why not create a
> dependency on the AsyncWeb library?
You are right here. I did not think at this possibility, I was
thinking of custom tailoring just the decoders/encoders for our own
purposes.
If we use an external binary library then I think there is no direct
advantage of using AsyncWeb (being MINA based)
and Jetty (or other HTTP servers) could be just as good for HTTP handling.
> Say you have a webserver already running on your vysper.org machine.
> Then you'd probably want that process to handle the HTTP-side of BOSH,
> too. So we need two basic modes of operation - in-process and separate
> processes.
For the separate processes, if you think of integration with Servlet
containers (Tomcat), then the Vysper Bosh endpoint would have to
implement servlet API, what do you think if this will be another
Vysper endpoint. Who will want to use Servlet containers could plug
that endpoint, and who will want a full Bosh XMPP server will use just
Vysper.
> You draw above: "stanza creation --> Bosh IoHandler"
> I don't understand that. Do you mean SessionContext?
I meant (assumed without drawing it) that the session context is
extracted (as is now in Vysper) from the IoSession in the
IoHandler#messageReceived()
My encoding scheme was more concerned how the parsing is done until it
reaches the Bosh IoHandler.
> I'd like us to evaluate Jetty, too. It's properly maintained and it
> implements the most recent standards in async web processing. WDYT?
I agree, initially I inclined towards AsyncWeb because it is MINA
based and because we're using the same mailing list :)
Bogdan
Re: Implement WebSockets/BOSH for XMPP AJAX clients
Posted by Niklas Gustavsson <ni...@protocol7.com>.
On Mon, Apr 19, 2010 at 11:49 AM, Bernd Fondermann
<bf...@brainlounge.de> wrote:
>> To me (given finite resources), I think in-process (that is, in
>> Vyspers process) is the most interesting option for us right now. This
>> is where a Vysper implementation of BOSH can add some value.
>
> Vysper is designed to be embedded easily, for example in a DI-container
> environment or a Tomcat, a Jetty etc. You could say this is still
> in-process, and it is, but the container might already have bound HTTP
> ports.
Agreed, but would you think this use case would be common enough to
make it worth implementing? Servlets are not the perfect environment
for long lived HTTP connections.
Besides, isn't this what we got XEP-0156 to solve for us?
>> For the
>> separate process, there are already generic BOSH gateways out there.
>
> Which? JabberHTTPBind isn't. I didn't look into
> http://kenai.com/projects/jbosh/pages/Home
> but it seems it isn't, too.
>
> But what I really like to see is a solution which is capable of blending
> into a servlet engine, e.g. does not re-implement HTTP, but rather is a
> Servlet.
Right, I assumed we were talking about a generic BOSH gateway.
> I'm ok with separating processes later, but designing with that in mind.
Fair enough.
/niklas
Re: Implement WebSockets/BOSH for XMPP AJAX clients
Posted by Bernd Fondermann <be...@googlemail.com>.
On Tue, Apr 20, 2010 at 01:08, Bogdan Ciprian Pistol
<bo...@gmail.com> wrote:
> On Mon, Apr 19, 2010 at 12:49 PM, Bernd Fondermann
> <bf...@brainlounge.de> wrote:
>>> For the
>>> separate process, there are already generic BOSH gateways out there.
>>
>> Which? JabberHTTPBind isn't. I didn't look into
>> http://kenai.com/projects/jbosh/pages/Home
>> but it seems it isn't, too.
>
> At http://xmpp.org/tech/bosh.shtml there are 4 standalone Bosh
> connection managers listed: Araneo, JabberHTTPBind, Punjab and rhb.
> Though I did not test them, I only looked at their documentation.
>
> Bernd, why JabberHTTPBind isn't? On their home page they say they are
> implementing Bosh and they are also listed at XMPP as a Bosh
> implementation.
It's unmaintained and out-dated. Patches are pending and not applied.
If I remember correctly, I hear Stefan say that he would do things
different now.
Bernd
Re: Implement WebSockets/BOSH for XMPP AJAX clients
Posted by Bogdan Ciprian Pistol <bo...@gmail.com>.
On Mon, Apr 19, 2010 at 12:49 PM, Bernd Fondermann
<bf...@brainlounge.de> wrote:
>> For the
>> separate process, there are already generic BOSH gateways out there.
>
> Which? JabberHTTPBind isn't. I didn't look into
> http://kenai.com/projects/jbosh/pages/Home
> but it seems it isn't, too.
At http://xmpp.org/tech/bosh.shtml there are 4 standalone Bosh
connection managers listed: Araneo, JabberHTTPBind, Punjab and rhb.
Though I did not test them, I only looked at their documentation.
Bernd, why JabberHTTPBind isn't? On their home page they say they are
implementing Bosh and they are also listed at XMPP as a Bosh
implementation.
Bogdan
Re: Implement WebSockets/BOSH for XMPP AJAX clients
Posted by Bernd Fondermann <bf...@brainlounge.de>.
Niklas Gustavsson wrote:
> Disclaimer, I'm still way behind on all fronts due to my trip to Korea
> being somewhat extended due to that ash cloud. But, I'm now home and
> trying to catch up :-)
>
> On Sun, Apr 18, 2010 at 9:33 PM, Bernd Fondermann
> <be...@googlemail.com> wrote:
>> I didn't check with AsyncWeb, but I guess the patch copies its source
>> code over to Vysper? I don't see a point in doing so. Why not create a
>> dependency on the AsyncWeb library?
>
> I also have not yet reviewed the patch, but +1 to depending on the
> binary rather than pulling in source code.
>
>> Say you have a webserver already running on your vysper.org machine.
>> Then you'd probably want that process to handle the HTTP-side of BOSH,
>> too. So we need two basic modes of operation - in-process and separate
>> processes.
>
> When you say webserver, would that be a servlet container or something else?
Servlet container.
> To me (given finite resources), I think in-process (that is, in
> Vyspers process) is the most interesting option for us right now. This
> is where a Vysper implementation of BOSH can add some value.
Vysper is designed to be embedded easily, for example in a DI-container
environment or a Tomcat, a Jetty etc. You could say this is still
in-process, and it is, but the container might already have bound HTTP
ports.
> For the
> separate process, there are already generic BOSH gateways out there.
Which? JabberHTTPBind isn't. I didn't look into
http://kenai.com/projects/jbosh/pages/Home
but it seems it isn't, too.
But what I really like to see is a solution which is capable of blending
into a servlet engine, e.g. does not re-implement HTTP, but rather is a
Servlet.
I'm ok with separating processes later, but designing with that in mind.
>> I'd like us to evaluate Jetty, too. It's properly maintained and it
>> implements the most recent standards in async web processing. WDYT?
>
> Agreed, however for this project I think we should choose one primary
> target.
+1.
> If Jetty fits the reqs, then that's a fine option to me. Also,
> Jetty supports WebSockets already, which would be interesting if we
> choose to go that path later on.
+1.
Bernd
Re: Implement WebSockets/BOSH for XMPP AJAX clients
Posted by Niklas Gustavsson <ni...@protocol7.com>.
Disclaimer, I'm still way behind on all fronts due to my trip to Korea
being somewhat extended due to that ash cloud. But, I'm now home and
trying to catch up :-)
On Sun, Apr 18, 2010 at 9:33 PM, Bernd Fondermann
<be...@googlemail.com> wrote:
> I didn't check with AsyncWeb, but I guess the patch copies its source
> code over to Vysper? I don't see a point in doing so. Why not create a
> dependency on the AsyncWeb library?
I also have not yet reviewed the patch, but +1 to depending on the
binary rather than pulling in source code.
> Say you have a webserver already running on your vysper.org machine.
> Then you'd probably want that process to handle the HTTP-side of BOSH,
> too. So we need two basic modes of operation - in-process and separate
> processes.
When you say webserver, would that be a servlet container or something else?
To me (given finite resources), I think in-process (that is, in
Vyspers process) is the most interesting option for us right now. This
is where a Vysper implementation of BOSH can add some value. For the
separate process, there are already generic BOSH gateways out there.
> I'd like us to evaluate Jetty, too. It's properly maintained and it
> implements the most recent standards in async web processing. WDYT?
Agreed, however for this project I think we should choose one primary
target. If Jetty fits the reqs, then that's a fine option to me. Also,
Jetty supports WebSockets already, which would be interesting if we
choose to go that path later on.
/niklas