The more separation we have of features and core the better. Of course this needs to be balanced against short term pain for possible long term gain.
Sent from my mobile device. On 27 Oct 2010, at 18:13, Scott Wilson <[email protected]> wrote: > Another consideration here is the extent to which we want in future to > decouple the core Wookie widget server from the Wave feature. > > Unlike other Feature extensions it has specific code in the core server - > WaveAPI, WaveAPIImpl, SharedDataKey, Participant, the DWR servlet descriptor > etc. > > I guess one thing the Node experiments have been useful for is identifying > how we could more cleanly separate out the Wave feature from the core - even > if it is implemented using DWR. > > The model I've used in the current iteration of my experimental work has been > to push both the SharedDataKey and the Widget Viewer object into the instance > preferences - a bit of a hack, but it means that the whole business of > managing participants, shared data, notifications and so on is moved out of > the Wookie server code and into the Wave implementation. In this case its > Node.js, but it could just as easily be the current implementation factored > out into a separate service. > > On 27 Oct 2010, at 12:16, Scott Wilson wrote: > >> On 27 Oct 2010, at 10:37, Bernhard Hoisl wrote: >> >>>> Odd, if I delete those lines it doesn't work at all on Safari, on Firefox >>>> it works for a few deltas before it stops working. This is using the >>>> default local Jetty/Derby setup. Are you testing this on Tomcat? >>> >>> No, I am using Wookie in standalone mode and tried it with Firefox (were it >>> works). Strangely, Chrome and Opera didn't respond, too. >> >> I've been playing around with it some more, and noticed that while in >> Firefox the transfer encoding of the response for DWR is "chunked" (as you'd >> expect for comet) for Safari its "identity". >
