- From: Jukka Zitting <jukka.zitting@gmail.com>
- Date: Thu, 12 Aug 2010 19:54:41 +0200
- To: WebDAV <w3c-dist-auth@w3.org>
Hi, On Thu, Aug 12, 2010 at 10:36 AM, Julian Reschke <julian.reschke@gmx.de> wrote: > Proposal for work on an efficient, browser-friendly, HTTP-based > communication protocol for fine-grained information exchange Sounds useful! See [1] for a few basic use cases and requirements I outlined for such a protocol last year. It seems like the proposed protocol could match these needs well, and I'd be eager to participate in ironing out the details. See below for some initial comments. [1] http://jukkaz.wordpress.com/2009/11/18/content-repository-over-http/ > [... WebDAV / Atom(Pub) ...] > Both of those protocol specifications are not easily consumed by websites > and applications running current browsers and require a lot of client-sided > scripting to cover simple read and write use cases. I'd add that also on server-side processing JSON or HTML forms is usually easier than handling WebDAV or AtomPub. > # Data Model > > 1) Define a collection model (hierarchy, naming), and a representation > format. > > Can we re-use the WebDAV collection model here? Web application authors > probably would prefer a JSON representation, so can we simply define this as > an alternate representation of a DAV:multistatus description of a > collection? It would be good if anything that can be expressed by this protocol could be straightforwardly mapped to WebDAV and/or Atom. The reverse does not need to be true, I'd rather go for simplicity than strive for a full one-to-one mapping with another protocol. > 4) Define a property model (something like the intersection between WebDAV > properties and Java Content Repository (JSR-283) properties?) As above, I'd focus on core property types shared by existing standards. > # URIs for collection browsing > > Assign either hardwired or discoverable URIs for inspecting collections (URI > templates?). Or maybe link relations for collection navigation (similar work > for versioning: RFC 5829). I'd rather avoid hardwiring URIs. > Expected deliverables from this activity would be: > > 1) Definition of a very simply data model and a representation format for it > (required JSON, optionally XML). > > 2) A format suitable for manipulating the data format above using PATCH > (potentially tunneled through POST). > > 3) A binding from multipart/form-data/POST to this model. > > 4) A separate (?) document explaining how these ingredients would be > combined in practice. 5) A test suite for validating compliance of implementations. (Not sure if this fits the scope of deliverables from an IETF WG, but should at least be pursued as a parallel effort.) > PS: people not familiar with the IETF may want to have a look at > <http://www.ietf.org/tao.html> Thanks! This was my first post here, so let me briefly introduce myself: I've been working with open source content management since -97 and for the past few years I've been focusing on Apache Jackrabbit and other related Apache projects. I work for Day Software and have participated in the JCR standardization effort in the JCP. I'm from Finland, but currently based in Basel, Switzerland. BR, Jukka Zitting
Received on Saturday, 14 August 2010 03:14:49 UTC