[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [cmis-browser] Comments before proceeding with spec
To get around #4, should we not just standardize support around the HTTP
header X-Method-Override?
It's used by many protocols in the web today to allow you to tunnel
DELETE / PUT via POST in those environments like #4.
On a related note to #2, is anyone looking into supporting the new
behaviors in HTML 5 File API and Drag and Drop APIs? If not, I would be
happy to put together a proposal.
Thanks,
---------------------------------------
Derek Carr
IBM Collaboration Solutions
(919) 254-8592 (t/l 444)
---------------------------------------
From: Jens HĂĽbel <jhuebel@opentext.com>
To: Gregory Melahn/Raleigh/IBM@IBMUS
Cc: <cmis-browser@lists.oasis-open.org>
Date: 11/12/2010 10:16 AM
Subject: RE: [cmis-browser] Comments before proceeding with spec
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
(Embedded image moved to file: pic09586.gif)Inactive hide details for Jens
HĂĽbel ---11/11/2010 12:27:08 PM---Thanks Greg,Jens HĂĽbel ---11/11/2010
12:27:08 PM---Thanks Greg,
From: Jens HĂĽbel <jhuebel@opentext.com>
To: Gregory Melahn/Raleigh/IBM@IBMUS
Cc: <cmis-browser@lists.oasis-open.org>
Date: 11/11/2010 12:27 PM
Subject: RE: [cmis-browser] Comments before proceeding with spec
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
(Embedded image moved to file: pic13169.gif)Inactive hide details for Jens
HĂĽbel ---11/11/2010 07:25:59 AM---HI all,Jens HĂĽbel ---11/11/2010 07:25:59
AM---HI all,
From: Jens HĂĽbel <jhuebel@opentext.com>
To: <cmis-browser@lists.oasis-open.org>
Date: 11/11/2010 07:25 AM
Subject: [cmis-browser] Comments before proceeding with spec
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
