Re: Proposal for work on an efficient, browser-friendly, HTTP-based communication protocol for fine-grained information exchange

On Sun, Aug 15, 2010 at 5:10 AM, Julian Reschke <julian.reschke@gmx.de>wrote:

> On 13.08.2010 10:02, Wenbo Zhu wrote:
>
>> ...
>>
>>    # Data Model
>>
>>    1) Define a collection model (hierarchy, naming), and a representation
>>    format.
>>
>> I have seen many debates around representation formats when the
>> underlying meta-model is often ignored ... and the meta-model should
>> cover, in addition to hierarchy, relations. And naming should allow for
>> different representations too, e.g. with the URI template[] being one of
>> them.
>>
>
> I think we need to be careful; if we over-engineer the data model we may
> scare away parts of the audience we want to include. It should be possible
> to define something that has an easy-to-use JSON representation but still
> have a solid model in the background.
>
> Including relations into the model makes sense to me. Links and link
> relations are important.
>
> I'm not sure I understand the point about naming; could you elaborate?
>
Separate the logic naming scheme from its syntactic representation ...  and
the former should be derived from the "background model". When relationships
are included, entities may be addressed via links too.



>
>  ...
>>
>>    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.
>>
>>    Extensions to WebDAV and mappings from/to WebDAV could be useful, but
>>    would not be a core part of this activity. (That is, we can do without
>>    if no volunteers speak up).
>>
>>
>> Resource-based concurrency-control and sync (revision logs) specs may be
>> developed on top of these deliverables as well.
>>
>
> Concurrency control as in locking? (be it optimistic or pessimistic)
>
Yes.


>
> Best regards, Julian
>