OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

cmis-browser message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Initial Comments


Hi All,

I finally had a chance to quickly go through the document.

I am happy actually make some of the edits later directly in the
document, but I thought I'd ask for comments on a couple of things
here first:

---------------------
(1) I think we should cover the usecases (sort of: "what are we trying
to achieve with this binding") in the document.
and of course I agree that it includes the simple consumption by a
browser for reading (via js and display in a browser), simple write
(via js and form post file upload).

I took the following from:
http://xml.coverpages.org/Nuescheler-CMIS-BrowserBindings.pdf

---
3.1 Simple Reading
A simple browser based application should be able to retrieve content
from the repository and make  sense of the properties and display
documents (content stream).
The specification should allow the simple build of a “CMIS browser
application” with just a few lines of javascript to satisfy the
mash-up use case.
After browsing for a “document”, the “document” should be displayed
with a proper resolution of all the relative references pointing to
other documents in the CMIS repository.
When displaying a document in a browser (such as an HTML file) the
relative URL references need to be kept intact, this includes for
example typical HTML elements like
<a href=”other.html”>
or
<img src=”images/my.png”>.

3.2 Simple Writing
Creating a simple HTML form in a browser should be enough to update
properties and the content stream. The names of properties
(potentially the relative paths) are addressed using form field names
in the browsers.
Just uploading a file is as simple as having one
<input type=”file”>
posting the form to the parent folders child list.
To create a custom way to update or create content in CMIS is as
simple as setting up a simple web form and POSTing it to the
respective URL identifying the document or folder.

3.3 Batch Writing
Posting a number of documents to the repository or modifying a larger
number of properties in the repository is as simple as creating a more
complex form.
Given the fact that some operations are not expressed in a simple and
efficient manner by the form
fields name value pairs,  a “patch” mechanism can be used that is
applied against the repository.
This provides a more efficient way from a network perspective but also
allows javascript applications to interact with the repository from
the browser client without having to simulate full form submissions.

---

---------------------
(2) I think it would be great if the examples also had the full
response, currently they only have headers for the request.
---------------------
(3) The date format specified seems to be a timestamp and the date
format used seems to be be the iso-8601. Since the goal is probably to
keep things as simple as possible i would like to propose to use the
format as loosely proposed by Date.toString() (eg. Mon Aug 09 2010
10:57:07 GMT+0200 (CET)) since the iso-8601 is a nightmare to parse on
the client-side and the timestamp is meaningless to humans.
---------------------
(4) While JSON responses and proper HTTP response codes seem
reasonable to go with it is hard to impossible to get to the
information depending on the browser and the operation. Assuming that
someone would do a file upload with a multipart post there is no way
for a js operation to get to the response. It seems like the only way
to respond to that so it can be processed by a javascript application
is to respond with a 200 and an HTML response, which of course is very
undesirable.
---------------------
(5) The spellchecker and auto-correct functions seem to have created a
bit of a mess ;) There are a number of things like "cmis:objected" and
interesting quotation marks, but i think it makes sense to go through
that a later stage.
---------------------

I am happy to log all of the above as JIRA issues but I think we don't
have a component yet. Are there any ideas/guidelines on how we want to
log these issues?

What do you guys think of doing the authoring process in a google docs
document that would give all the editors access?

regards,
david
-- 
David Nuescheler
Chief Technology Officer
mailto: david.nuescheler@day.com

web:  http://www.day.com/ http://dev.day.com
twitter: @davidnuescheler


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]