[Osr-101] Neutron specs

[Thomas Comiotto]

Hi Andi

> Actually, we could leave out <edit>, but only under the assumption 
> that whenever you receive a document by way of the <checkout> or 
> <open> address, this means that you can edit it. Or with other words: 
> we cannot provide different views apart from edit, i.e. if you want to 
> checkout a document for e.g. simple displaying instead of editing, 
> this wouldn't work, because we always had to deliver a document ready 
> for editing when someone accesses the checkout URI.
>

I am not sure if I understand. First of all, I would keep Neutron to 
the bare minimum in terms of what's needed to remote authoring. Leave 
alone the idea of mapping client GUI elements to protocol commands. 
That's a design desicion that no client side developper wants to be 
forced in and will not pay off in the long run.

Instead let the client application decide on what to do with the 
available methods/commands and *keep them simple*. If for instance 
locking a resource is required and a write lock can be aquired a client 
can provide for editing, otherwise just for viewing.

Opening/retrieving a doc should be considered being always possible, 
whether in read-only or in read/write mode. The open method is 
equivalent to simply accessing a resource by its URI in almost all 
cases (except of servers want to provide a seperate service endpoint 
for Neutron). The URI of the resource could also serve as a good 
identifier to refer to the resource, as opposed to using the open 
command for that because the open command suggest being, well, just the 
open command.

Also see http://wyona.com/pipermail/phoenix/2006-August/000367.html

Checkout is a shortcut of open + lock. I am still not convinced re this 
shortcut when considering servers with exclusive/shared locks. I don't 
think it makes sense but Michi does, well..

To make two more points re considering content editable/read-only: 
Ulysses for instance provides a "save to local filesystem" function - 
so every retrieved document is considered editable. And, Neutron is a 
content authoring protocol so the implied usecase is to edit.

>>>
>> you mean that Neutron could also be placed on top of other protocols 
>> than just HTTP?
>
> Of course. But this can also be acomplished using the format we are 
> using now, because the scheme part of the URI basically defines the 
> protocol. Using the format above, we had to introduce "*Method" 
> attributes for every protocol a user could potentially be interested 
> in.
>

Agreed. But I wanted to make the point that not every protocol uses the 
semantics of a "method", therfore "method" implies using a scheme that 
supports it, HTTP for instance. Anyway that's minor issue:)


> Therefore, I basically vote -1 for such a format.
>
>>> Otherwise I hope you like the changes I forgot to mention here:)
>> will check :-). I think we should introduce "Paces" as Atom does in 
>> order to discuss changes, otherwise I am
>> afraid that we get into a commit war at some point ;-)
>
> Heh. :) But to be honest, I would rather have the complete spec hosted 
> in a Wiki, where we can add annotations, etc. And then, we could also 
> add paces there. Just carrying them around in mails is cumbersome, so 
> we should have a place where we can look up the original pace 
> suggestion. (BTW, the APP WG does also have their paces in a Wiki.)
>

Very much agreed. Still it ain't too hard to collect what has been 
posted on this list luckily - and these points will have to be further 
discussed on this list;)

--
Bests
Thomas