> The server can use a sax parser, they do work on streams; there is no magic > required.
Using a SAX parser does not tell you where the data ends. This may be irrelevant. > Resending multiple stanzas isn't really any different than in > regular syntax either, because when the server acks you a rid you resend as > expected; essentially you break up your <body> payload into sub 2K chunks > and make them a single text node in the <body> (the schema in 124 does not > reflect that IIRC). Ok, I am grokking it now. In my mental model the server was having to receive all partial requests to start processing. With sax style parsing you can support resends. This still puts more burden on the client to split up data. (As a side note, splitting up data is needed in general to handle very large single stanzas, but this cannot be done inside the current BOSH spec I don't think). In any case, ASS is a giant hack, and one that is avoidable by using some other way to do the cross site stuff. This is a hot topic in AJAX land at the moment, and I'm sure another solution will be forthcoming. It should have never made it into the already-at-Draft-status BOSH XEPs and should be moved to a historic or experimental xep. I'm pretty sure the other cross site solutions will not be BOSH specific, and so will not need a XEP of their own, unless we do an informational one. Personally, I don't see the single domain limitation as being that bad. There is nothing preventing you from proxying Punjab behind nginx and connecting to any jabber server you want that way. I know Blaine had a use case or two that required a separate domain, but this seems limited to extreme cases like Twitter scalability levels. Even then I'm not sure it is absolutely necessary, or just a big convenience. Note that flash has similar limitations as well. I talked with Fritzy about Seesmic's AS3 XMPP implementation, and that limits you to a local jabber server IIRC. I suppose you could get around that with a jabber proxy too, which is essentially all BOSH is. jack.
