- From: Ted Thibodeau Jr <tthibodeau@openlinksw.com>
- Date: Mon, 10 Nov 2014 09:55:01 -0500
- To: Sandro Hawke <sandro@w3.org>
- Cc: Linked Data Platform WG <public-ldp-wg@w3.org>
Sandro, all -- A couple of comments on initial skim... On Nov 9, 2014, at 12:06 PM, Sandro Hawke <sandro@w3.org> wrote: > == 2. Change Notification to Web Servers > > If a server acting on behalf of the end-user i.e., acting as a Client against the other Servers. The change publication/subscription should be implemented as a general Cilent-Server feature, something like, oh, say, PubSubHub. > is going to aggregate data from other servers, it needs to be able to keep its copy in sync. Traditional web cache + polling works only when it's okay to be seconds or minutes out of date; many multi-user apps require much more responsiveness than that, so we see a need for one server to be able to subscribe to change notification from another. > > One might want something like PATCH to make this more efficient, but at the moment it looks like we can keep the resources small enough that it doesn't matter. The size of a single change notification resource may well be tiny, but as the number of such notifications increase, both from one and many servers, efficiency is going to become more important. > == 3. Change Notification to Web Clients > > Similarly, Web Apps often need to know immediately when data has changed. While it might be nice to have this be the same protocol as (2), our preliminary investigation suggests the engineering trade-offs make that impractical. So, this needs to be its own protocol. Probably it's just a tweak to the query protocol where query results, rather than being a single response collecting all the results, are ongoing add-result and remove-result events. I think this is mostly a scale-of-payload kind of question. The protocol should have (optimally client-specified) timing and/or number-of-changes parameters; this lets it remain one protocol for both this "Just A Client" and the above "Server as Client" subscribers. Regards, Ted -- A: Yes. http://www.guckes.net/faq/attribution.html | Q: Are you sure? | | A: Because it reverses the logical flow of conversation. | | | Q: Why is top posting frowned upon? Ted Thibodeau, Jr. // voice +1-781-273-0900 x32 Senior Support & Evangelism // mailto:tthibodeau@openlinksw.com // http://twitter.com/TallTed OpenLink Software, Inc. // http://www.openlinksw.com/ 10 Burlington Mall Road, Suite 265, Burlington MA 01803 Weblog -- http://www.openlinksw.com/blogs/ LinkedIn -- http://www.linkedin.com/company/openlink-software/ Twitter -- http://twitter.com/OpenLink Google+ -- http://plus.google.com/100570109519069333827/ Facebook -- http://www.facebook.com/OpenLinkSoftware Universal Data Access, Integration, and Management Technology Providers
Received on Monday, 10 November 2014 14:55:30 UTC