atom feed11 messages in org.oasis-open.lists.cmis-browserRE: [cmis-browser] Groups - CMIS Brow...
FromSent OnAttachments
mel...@us.ibm.comJul 25, 2010 2:21 pm 
mel...@us.ibm.comJul 27, 2010 9:01 am 
Ryan McveighJul 28, 2010 2:38 pm 
Jens HübelJul 28, 2010 11:48 pm 
Derek W CarrJul 29, 2010 6:21 am 
Gregory MelahnAug 8, 2010 2:46 pm.gif, .gif
mel...@us.ibm.comAug 8, 2010 3:00 pm 
Gregory MelahnAug 8, 2010 3:25 pm.gif, .gif
Florian MüllerAug 9, 2010 6:52 am.gif, .png, .png
Gregory MelahnAug 9, 2010 7:23 am.gif, .gif, .gif, 1 more
Derek W CarrAug 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
List:org.oasis-open.lists.cmis-browser

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
simple.

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.

Jens

-----Original Message----- From: Ryan Mcveigh [mailto:ryan@oracle.com] Sent: Mittwoch, 28. Juli 2010 23:39 To: cmis@lists.oasis-open.org Subject: RE: [cmis-browser] Groups - CMIS Browser Binding Proposal - v0.1
(cmis-spec-v0.1-browserbinding.doc) uploaded

Hi folks,

I've added my own comments directly to the document and used change tracking to
do so. I uploaded the updated document here:
http://www.oasis-open.org/apps/org/workgroup/cmis-browser/download.php/38820/cmis-spec-v0.1-browserbinding%20-%20rm.doc

I'd appreciate your feedback. Thanks,

-----Original Message----- From: mel@us.ibm.com [mailto:mel@us.ibm.com] Sent: Tuesday, July 27, 2010 10:02 AM To: cmis@lists.oasis-open.org Subject: [cmis-browser] Groups - CMIS Browser Binding Proposal - v0.1
(cmis-spec-v0.1-browserbinding.doc) uploaded

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

Download Document: http://www.oasis-open.org/committees/download.php/38791/cmis-spec-v0.1-browserbinding.doc

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