Greg,
let me quickly summarize the reasoning I have received so far:
1. HTML forms support only GET/POST as upload mechanism for content
2. JS code can not access file system as alternative mechanism for upload because it runs in sand box
3. Not all browsers support PUT/DELETE in XmlHttpRequest (not sure if this is still relevant)
4. Firewalls/ web servers may block PUT/DELETE requests
So, now we have this written down and I think this is something that should be documented and more clearly mentioned in the spec.
My suggestion would be to define and support PUT and DELETE requests and in addition as an alternative access path using GET and POST for environments where we have these restrictions. I think this would give us a cleaner protocol and should not be much more effort.
If we learn over time that a more RESTful approach is too painful or prevents an efficient browser protocol regarding number of roundtrips etc. I am happy to drop this. But I would not make this decision in the current state of the spec already.
JSON on top of AtomPub URLs: I am sure we will get asked this question… There still would be notable differences, but we have some shortcomings in AtomPub that we want to solve with JSON.
From: Gregory Melahn [mailto:melahn@us.ibm.com]
Sent: Donnerstag, 11. November 2010 19:14
To: Jens Hübel
Cc: cmis-browser@lists.oasis-open.org
Subject: RE: [cmis-browser] Comments before proceeding with spec
Jens,
On GET and POST, I think it is a big issue. We want a low barrier of entry here, not one requiring a developer use xml http requests for example. I know we can do it (for example that is how the Firefox connector was built) but it's not simple and leaves out one important audience of amateur or casual developers. Not to mention that such a design requires production servers be reconfigured to allow requests with those verbs, though x-method-override can solve that problem I suppose.
As far as RESTfuness, I am not against it on principle but there will be cases where we need to go outside that model to keep it simple, again for that browser developer, and more efficient (not require multiple requests). We are not going to describe this as a RESTful binding though we should as much as possible borrow from existing resource definitions
Another way of thinking about is to ask what would we accomplish if all we did was add an additional representation (JSON in lieu of XML) on top of the existing AtomPub binding. Would we really have made the life of a web developer looking to use CMIS any better?
Gregory Melahn
STSM
IBM Collaboration Solutions
melahn@us.ibm.com
919 254 0295
Jens Hübel ---11/11/2010 12:27:08 PM---Thanks Greg,
|
|
|
|
|
|
|
|
|
|
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