On Wed, Mar 31, 2010 at 02:41, Bogdan Ciprian Pistol
<[email protected]> wrote:
> Hello,
>
> I am interested about this project for GSoC.
>
> I've started writing a PoC for this. I want to ask you if I'm going in
> the right direction.
>
> It would be nice if the server could handle both standard XMPP clients
> (5222) and xbosh (443 or 80). So MINA binds to 2 ports in TCPEndpoint
> (for this I added an extra xbosh configurable port in TCPEndpoint).
I prefer having a separate dedicated endpoint for BOSH, so we result
in 2 endpoints.
> The HTTP headers are decoded by XMLStreamTokenizer as XMLText
> (XMLRawToFragmentConverter#convert).
BOSH is a protocol. XMPP is a protocol. Each protocol deserves it's
own protocol handling code.
> So when receiving HTTP there would be 2 options:
> 1) To use the current XMLStreamTokenizer decoder and add a new <body/>
> o.a.v.xmpp.Stanza (ignoring the XMLText headers)
> 2) To have another decoder that decodes HTTP (having access to
> headers) and then process the <body/>.
> I know that xbosh says that we should ignore all the headers (except
> maybe Accept-Encoding), but maybe there is some use for them.
BOSH tunnels XMPP through HTTP. The spec says exactly how to do it.
The scope of this GSoC project is to have a working compliant BOSH
implementation.
If we have that, we might start think about going beyond.
>
> Another option would be to parse the XMLText thrown in
> XmppIoHandlerAdapter#messageReceivedNoStanza, but I incline to think
> that this is not the right place.
>
> I chose option 2) with the decoder option chosen like this:
>
> public ProtocolDecoder getDecoder(IoSession s) throws Exception {
> if (((InetSocketAddress) s.getLocalAddress()).getPort() ==
> xboshPort) {
> return new XBoshDecoder(new XMLStreamTokenizer(new
> StanzaBuilderFactory()));
> } else {
> return new XMLStreamTokenizer(new
> StanzaBuilderFactory());
> }
> }
>
> And the XBoshDecoder uses the Apache AsyncWeb HTTP codec that does a
> nice job at parsing HTTP.
>
> Do you think this is overkill? I have some doubts, but I like that all
> the HTTP information is available.
The specs are very clear about this. Please read XEP-0124, 3.
Architectural Assumptions, carefully.
There is a HTTP server running. This could be AsyncWeb HTTP, for
example, embedded into Vysper, but could also be a stand-alone
program/process.
This is a special webserver, though. It can extract XMPP stanzas from
HTTP requests and forward them to Vysper's core stanza handling + it
can receive stanzas and respond them back to HTTP agents.
> For SSL encryption I am thinking of putting the SSL filter by default
> if the port 443 is configured for xbosh. To configure 2 IO filter
> chains in MINA I don't know any other way but just to create a new
> NioSocketAcceptor with a different chain.
>
> I'll write more when I'll advance with the implementation.
Wait a second. We are not at implementation level at this point, you
are wasting time.
That's not how GSoC works.
If you want to get this into GSoC, please refer to
http://socghop.appspot.com/document/show/gsoc_program/google/gsoc2010/userguide#depth_students
If you already checked 1. and 2., you are at positon "3. Submitting
your proposal".
Don't take it easy. This is the most important step at all.
It's the basis for measuring you proposal against all the other
proposals from Apache.
Bernd
