I haven't been following the BOSH effort in full detail, but I wonder if
the cross-domain support has been documented somewhere in the "feature"
list for BOSH. :)
I know I mentioned earlier the capability to serve up a
"crossdomain.xml" file easily, and it sounded like everyone agreed, so
this might already be done.
Another cross-domain enabling feature to add at the very bottom of the
feature list is to support native XDR, via supporting special headers.
The standard is described here:
http://developer.yahoo.com/yui/3/io/#xdr
On 6/29/10 4:00 AM, Bogdan Ciprian Pistol wrote:
Week 5 - status report (http://vysper-gsoc2010.blogspot.com/2010/06/week-5.html)
The following tasks were scheduled for this week:
* SASL auth
* Resource binding
* Figuring out a general approach for routing stanzas to Vysper
and back to the BOSH client
Completed:
* SASL is done
* Session restart after SASL auth is implemented. It does not
forward the restart request from the BOSH client to Vysper, but
instead responds with the approriate features from
ServerResponses#getFeaturesForAuthentication(). The method is private
and I changed it (in the patch) to be public. If you think this is not
appropriate I will strip instead the response from
ServerResponses#getStreamOpener().
* Improved continuation implementation and "expires" (BOSH wait)
times. There was a problem with the previous continuation
implementation of "expire" because the "resume" on an expired
continuation (that has not "completed") is implicit (by Jetty) - and
now I use continuation listeners for expired requests that attach the
result to the continuation and then implicitly (by Jetty) in the
servlet doPost() I write the result (empty response) as if it were
resumed by me.
* Accumulated stanzas (more than the requests/responses available
- in code are stored in "delayedResponseQueue") are merged into a
single request for better efficiency (bandwidth, latency). There is a
potential problem here because some responses have specific attributes
that are problematic to merge, but actually this is not a problem
because only the session creation response and session restart (after
SASL auth) are in this case. The server and the client are not sending
extra req/resp in the SASL/restart phase and are waiting the response
from the other, so everything works OK with merged stanzas.
* Thread safe BoshHandler and BoshBackedSessionContext. (part of
the work was done earlier) If some client(s) send multiple requests
with the same SID then it is possible to have simultaneous requests in
BoshHandler, so BoshHandler is guarded by this by synchronizing on the
BoshBackedSessionContext (that is uniquely identified by its SID).
Also the writes coming from Jetty (when a continuation expires) and
from Vysper are also synchronized on the BoshBackedSessionContext,
this makes the BoshBackedSessionContext thread safe. When the session
is created initially in BoshHandler in doesn't need to be synchronized
because nobody knows the SID, also the "happens before relationship"
memory consistency is in-place because of the ConcurrentHashMap used
to store the session.
* The write requests of stanzas from Vysper are wrapped inside a
body wrapper before being sent to the clients.
* The stanzas from BOSH clients are stripped from their body
wrapper and sent for processing to Vysper.
Patches:
* https://issues.apache.org/jira/browse/VYSPER-214
Next:
* continue the client side implementation based on Strophe.js
Bogdan
