[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]