|mel...@us.ibm.com||Jul 25, 2010 2:21 pm|
|mel...@us.ibm.com||Jul 27, 2010 9:01 am|
|Ryan Mcveigh||Jul 28, 2010 2:38 pm|
|Jens Hübel||Jul 28, 2010 11:48 pm|
|Derek W Carr||Jul 29, 2010 6:21 am|
|Gregory Melahn||Aug 8, 2010 2:46 pm||.gif, .gif|
|mel...@us.ibm.com||Aug 8, 2010 3:00 pm|
|Gregory Melahn||Aug 8, 2010 3:25 pm||.gif, .gif|
|Florian Müller||Aug 9, 2010 6:52 am||.gif, .png, .png|
|Gregory Melahn||Aug 9, 2010 7:23 am||.gif, .gif, .gif, 1 more|
|Derek W Carr||Aug 10, 2010 8:29 am||.gif, .gif, .gif, 9 more|
|Subject:||RE: [cmis-browser] Groups - CMIS Browser Binding Proposal - v0.1 (cmis-spec-v0.1-browserbinding.doc) uploaded|
|From:||Jens Hübel (jhue...@opentext.com)|
|Date:||Jul 28, 2010 11:48:01 pm|
I agree to Ryan's comments about saving space/compression. We should focus on a
simple and consistent schema and not trying to squeeze everything into the
minimal number of bytes. If we have such requirements then a binary protocol
would be the right choice. Instead the principle should be to follow the domain
model where possible and to keep the JSON parsing and generator code compact and
I also would like to better understand why we use relative URI paths (section
1.2.3). In the AtomPub protocol we did not do this. What is the benefit? Is it
again saving space? We then need code to preprocess every link before we can
submit a request to it. Do we want this? This mechanism also implies the
restriction that all targets are beneath a common root URL. This is not the case
for all repositories. It may happen that the content for example is located on a
different server (take an Amazon S3 like store as a simple example). Another use
case is a virtual repository acting as a federator to other repositories.
From: Ryan Mcveigh [mailto:ryan...@oracle.com]
Sent: Mittwoch, 28. Juli 2010 23:39
Subject: RE: [cmis-browser] Groups - CMIS Browser Binding Proposal - v0.1
I've added my own comments directly to the document and used change tracking to
do so. I uploaded the updated document here:
I'd appreciate your feedback. Thanks,
From: mel...@us.ibm.com [mailto:mel...@us.ibm.com]
Sent: Tuesday, July 27, 2010 10:02 AM
Subject: [cmis-browser] Groups - CMIS Browser Binding Proposal - v0.1
changes reflecting Florian's comments. Added responseInfo and clarification on paging. Fixed a few typos.
-- Mr. Gregory Melahn
The document revision named CMIS Browser Binding Proposal - v0.1 (cmis-spec-v0.1-browserbinding.doc) has been submitted by Mr. Gregory Melahn to the CMIS Browser Binding SC document repository. This document is revision #1 of cmis-spec-v0.1-browserbinding.doc.
Document Description: This is the first iteration of the proposal, including some statements about the approach, and a few examples. It is still a skeleton document.
View Document Details: http://www.oasis-open.org/committees/document.php?document_id=38791
Revision: This document is revision #1 of cmis-spec-v0.1-browserbinding.doc. The document details page referenced above will show the complete revision history.
PLEASE NOTE: If the above links do not work for you, your email application may be breaking the link into two pieces. You may be able to copy and paste the entire link address into the address field of your web browser.
-OASIS Open Administration
--------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php