On Jul 2, 2006, at 10:58 AM, Harm Smit wrote: > BTW, in your setup, how would you make the interactions asynchronous?
1) Async+Poll: ---> PUT /bulbs/1 [state data] <--- 202 Acepted Location: /bulbs/1 ...poll /bulbs/1 with GET until you see that state has changed... 2) Asynch+Notification PUT /bulbs/1 [state data] <--- 202 Acepted Location: /bulbs/1 ---> WATCH /bulbs/1 Reply-To: mailto:[EMAIL PROTECTED] ...wait for mail to arrive.... (WATCH is non standard HTTP; this is no problem if you control the whole system (e.g. inside an intranet)) 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.) 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!! 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? Both of these for example come for free with HTTP - zero design- and zero implementation cost! 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/
