On Jul 2, 2006, at 6:34 PM, Steve Jones wrote: > > > Ahhh polling, the old running a watcher thread in the consumer, which > of courses more complexity on the caller.
Hmm...having a server in the caller waiting for notifications is less complex than having the caller periodically poll the server? What am I missing? > > > > (WATCH is non standard HTTP; this is no problem if you control the > > whole system (e.g. inside an intranet)) > > But doesn't this break the whole principle that HTTP is all you need? There is no principle that HTTP is all you need. There is a principle of a uniform interface. Making WATCH part of that is likely to happen for next gen HTTP. > I'd have expected something like > > PUT > <watch query="lightbulb/state" respond="http://me.com/listener> > > Which would make a call to my server via a PUT statement with the > current state. Either way leaves the big question of whom is calling > me when I receive the event. PUT's definition does not license that kind of use case. > > > > > Presumably, Polling with HEAD doesn't even have the overhead to > > justify the complexity of the notification based > > solution (the server maintaining the subscribers, the watcher > > maintaining a server to manage the Reply-To URI.) > > But the polling approach has the main overhead on the consumer, > assuming that the number of consumers > number of publishers then > polling is going to be a poor solution. Is it? Maybe in some scenarios, but not in the general case I guess. Any numbers? > > > > > And, BTW, the architectural style of a system does indeed make a > > difference regarding the assumptions one can make about certain of > > its properties such as performance!, maintainability or > evolvability!! > > I don't disagree, paticularly about the last two. Personally I'm > still struggling to see REST as anything beyond yet another A->B comms > implementation. Maybe if you'd dig deeper....? Do an example design, post it to rest- discuss and let's discuss it. Examples are usually best to learn > > > > Tell me, can the client component cache the return value of > > srv.GetBulbState()? Are you sure you can re-do the srvSetBulbState() > > function as often as you like? > > There really isn't any difference in either model in terms of > re-entrance and data latency, neither REST nor SOAP/WSDL address > either of those two problems. Hmmm...looking at REST's coverage of caching and HTTP's vast treatmet of the subject I wonder what leads you to that conclusion. > > For instance, lets assume that you are using REST to write to compact > flash and you call it 1 billion times, after a certain point it ceases > to be re-entrant as the compact flash can no-longer accept updates. > So what? The additional PUTs still do not do anything else beyond the first one. > > > > Both of these for example come for free with HTTP - zero design- and > > zero implementation cost! > > No they don't, see above. HTTP specifies nothing about data latency > or re-entrance, that is purely a systems design element. Unless you > are claiming that by using HTTP you can just keep calling back to the > server.. which means you fall into the trap of the trap of the eight > fallacies of network computing http://www.java.net/jag/Fallacies.html And which one do you mean exactly? And, speaking of "keeping calling back to the server".....Search engine crawlers do exactly that quite successfully and without breaking anything (except when someone implements GET in the wrong way) Jan > > > > > Jan > > > > > > > > > > > ------------------------ Yahoo! Groups Sponsor --------------------~--> Great things are happening at Yahoo! Groups. See the new email design. http://us.click.yahoo.com/TISQkA/hOaOAA/yQLSAA/NhFolB/TM --------------------------------------------------------------------~-> Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/service-orientated-architecture/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
