Thanks Greg,
How much is the lack of support PUT and DELETE still an issue? Don’t most platforms and all major browser support this now:
http://intertwingly.net/wiki/pie/PutDeleteSupport
Isn’t this a good example where we should look for a second access path for those specific environments that don’t support this instead of screwing up the design from the beginning?
I am just looking at the comments about Amazons SimpleDB in this discussion thread here: http://tech.groups.yahoo.com/group/rest-discuss/message/9999
All I am saying is that this a decision that has to be done carefully.
From: Gregory Melahn [mailto:melahn@us.ibm.com]
Sent: Donnerstag, 11. November 2010 14:56
To: Jens Hübel
Cc: cmis-browser@lists.oasis-open.org
Subject: Re: [cmis-browser] Comments before proceeding with spec
Thanks Jens,
The main design goal for the browser binding is to make it easier for developers to write browser apps that use CMIS content (of course). Part of that goal is answered by sticking to the technology limits (like using GET and POST etc) and part of is also answered by coming up with simple patterns that the more casual programmers in this space actually understand without wading through a big spec. I would not say that being RESTful is one of our design goals and in fact, could get in the way of our design goal of reaching casual programmers.
As far as resource definitions, the proposed schema does attempt to define resources, and so I am not sure I understand your meaning when you say you want to define resources as building blocks for the schema; I thought that is already what the proposed schema is trying to do in defining document, folders, policy etc that would the resources used in the service definitions Ryan also made a similar point so maybe I am just missing something that you could clarify.
I am all for using the mailing list more if that helps move the proposal forward. What will help more than anything would be a partial implementation in Chemistry which will be the real test of whether we got this right or not. The schema will help a lot with that,
Gregory Melahn
STSM
IBM Collaboration Solutions
melahn@us.ibm.com
919 254 0295
Jens Hübel ---11/11/2010 07:25:59 AM---HI all,
|
|
|
|
|
|
|
|
HI all,
thinking about dividing our work to make more progress I wonder if we should agree on certain design principles and building blocks to avoid that every service looks different.
I looked a bit at the critics we have received in the past and how we designed the AtomPub protocol. I came to the conclusion that I would try to identify resource and then http methods, requests and response formats. I would use thoise to define URL naming and query parameters. This would be more a RESTful way in contrast to start from the services in the domain model. No doubt that in the end we need both to be sure that we can map the entire CMIS domain model to the browser binding.
I think CMIS resources come in three flavors: simple entries, collections (or lists) and hierarchies. Some resources exist on its own (e.g. document, policy) and have an id. Some resources exist only in context of other resources (e.g. parent, rendition, content stream).
If we define schema definitions for basic resources, and design (or composition) patterns for collections and hierarchies as building blocks for the JSON schema we could achieve a certain consistency between the domain model services.
Talking about and identifying resources would also help us to compare the existing proposal for URL patterns (http://tools.oasis-open.org/issues/browse/CMIS-677) to other possible approaches.
I would also like to see if we could somehow document important design decisions. For example whether we define the JSON binding in a RESTful way or in non RESTful way is something that needs an agreement within the group and this decision should be documented. I also think the initial goals we discussed (less chattier than AtomPub, more browser friendly, reduce number of roundtrips for typical use cases, less expensive responses for a server) should be written down somewhere so that we can refer to them in the technical discussions.
A couple of things popped up in the last call that needs (at least for me) further clarification and discussion:
Why is a (more) RESTful design inappropriate for our purpose? Is this per se a contradiction to browser-friendly?
If we have certain issues in specific environments (like JavaScript libraries) or escaping issues with id syntax we carefully should evaluate how much this should impact our overall design or if we can find solutions or workarounds for these specific cases.
In no way I want to insist on a pure (or “religious” REST design), but I want to make sure that we get what we need. And these questions came up looking on the existing proposal.
Let me know what you think and let us try to make more use of the mailing list in addition to the conf calls for the discussions we need.
Jens