[vysper]HTTP CM to XMPP Server communication

[Bernd Fondermann <be...@googlemail.com>]

On Tue, Apr 20, 2010 at 00:44, Bogdan Ciprian Pistol
<bo...@gmail.com> wrote:
> 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 :)

And if we evaluate AsyncWeb we might come to the conclusion to use it,
since it's easy for us to maintain it.
This could be done in the scope of GSoC. Is this planned? I figure
that the implementation itself might not take the whole summer and
there might be time to prepend a technology study.

So I like to rewind myself and ask a question:
What approach should we use for HTTP CM <-> XMPP Server communication?
According to XEP-124 there are three possible solutions:

>>
This specification covers communication only between a client and the
connection manager.
It does not cover communication between the connection manager and the
server, since such communications are implementation-specific (e.g.,
a. the server might natively support this HTTP binding, in which case
the connection manager will be a logical entity rather than a physical
entity;
b. alternatively the connection manager might be an independent
translating proxy such that the server might believe it is talking
directly to the client over TCP; or
c. the connection manager and the server might use a component
protocol or an API defined by the server implementation).
<<
(I added the numbering a.-c.)


  Bernd

Re: [vysper]HTTP CM to XMPP Server communication

[Niklas Gustavsson <ni...@protocol7.com>]

On Tue, Apr 20, 2010 at 10:26 AM, Bernd Fondermann
<be...@googlemail.com> wrote:
> And if we evaluate AsyncWeb we might come to the conclusion to use it,
> since it's easy for us to maintain it.
> This could be done in the scope of GSoC. Is this planned? I figure
> that the implementation itself might not take the whole summer and
> there might be time to prepend a technology study.

Agreed, I think it would be beneficial to look into more detail on the
choice of platform. Personally, looking more into the WebSocket
implementation in Jetty
(http://dev.eclipse.org/svnroot/rt/org.eclipse.jetty/jetty/trunk/jetty-websocket)
makes me lean more towards basing it on Jetty.


> So I like to rewind myself and ask a question:
> What approach should we use for HTTP CM <-> XMPP Server communication?
> According to XEP-124 there are three possible solutions:
>
>>>
> This specification covers communication only between a client and the
> connection manager.
> It does not cover communication between the connection manager and the
> server, since such communications are implementation-specific (e.g.,
> a. the server might natively support this HTTP binding, in which case
> the connection manager will be a logical entity rather than a physical
> entity;
> b. alternatively the connection manager might be an independent
> translating proxy such that the server might believe it is talking
> directly to the client over TCP; or
> c. the connection manager and the server might use a component
> protocol or an API defined by the server implementation).

a. would seem to be the easiest option, at least to start with.

/niklas

Re: [vysper]HTTP CM to XMPP Server communication

[Bernd Fondermann <be...@googlemail.com>]

On Tue, Apr 20, 2010 at 18:23, Bogdan Ciprian Pistol
<bo...@gmail.com> wrote:
> On Tue, Apr 20, 2010 at 11:26 AM, Bernd Fondermann
> <be...@googlemail.com> wrote:
>> And if we evaluate AsyncWeb we might come to the conclusion to use it,
>> since it's easy for us to maintain it.
>> This could be done in the scope of GSoC. Is this planned? I figure
>> that the implementation itself might not take the whole summer and
>> there might be time to prepend a technology study.
>
> In the proposal it is planned that in the community bonding period
> prototyping study will be done.

The GSoC proposal is not public, unfortunately.

> I think you can consider that the prepended technology study is
> included in the prototyping period.
>
>> So I like to rewind myself and ask a question:
>> What approach should we use for HTTP CM <-> XMPP Server communication?
>
> I agree with Niklas that option a. is appropriate to start with.

+1

  Bernd

Re: [vysper]HTTP CM to XMPP Server communication

[Bogdan Ciprian Pistol <bo...@gmail.com>]

On Tue, Apr 20, 2010 at 11:26 AM, Bernd Fondermann
<be...@googlemail.com> wrote:
> And if we evaluate AsyncWeb we might come to the conclusion to use it,
> since it's easy for us to maintain it.
> This could be done in the scope of GSoC. Is this planned? I figure
> that the implementation itself might not take the whole summer and
> there might be time to prepend a technology study.

In the proposal it is planned that in the community bonding period
prototyping study will be done.
I think you can consider that the prepended technology study is
included in the prototyping period.

> So I like to rewind myself and ask a question:
> What approach should we use for HTTP CM <-> XMPP Server communication?

I agree with Niklas that option a. is appropriate to start with.

Bogdan