- From: Wilde, Erik <Erik.Wilde@emc.com>
- Date: Mon, 21 Jan 2013 10:41:54 -0500
- To: Roger Menday <roger.menday@uk.fujitsu.com>
- CC: John Arwe <johnarwe@us.ibm.com>, "public-ldp-wg@w3.org Group" <public-ldp-wg@w3.org>
hello roger. On 2013-01-21 16:22 , "Roger Menday" <roger.menday@uk.fujitsu.com> wrote: >>indeed, a very bad typo. >> >> "there may be constraints on payload, but defining and enforcing those >> should not be something LDP is concerned with." >I'm curious. I believe that LDP should be used by people developing Bug >Tracker APIs, Cloud Management APIs, Photo Management APIs, etc, etc, etc >- (using the widespread interpretation of the word "API") ... I think >these kind of scenarios are important. But, does anyone else see it that >way, or am I in the wrong group :) ? you're most definitely not, but we're not in the business of developing Bug Tracker APIs, Cloud Management APIs, or Photo Management APIs. we're developing a foundation protocol, and each of those APIs should be able to take our protocol, and refine it into a more specialized domain protocols, if they want to. our only concern, though, is the generic protocol, so that all you could build would be the LDP equivalent of a "write-enabled feed reader". i fully agree that all of the scenarios you listed are important, but all we need to do is make sure that we have extension points that the more refined protocols can be based on. in the end, a generic client should work against all services using LDP as the foundation, so that i can, for example, in one "LDP feed" see all my aggregated updates from my Bug Tracker, Cloud Management, and Photo Management services. cheers, dret.
Received on Monday, 21 January 2013 15:43:56 UTC