jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julian Reschke <jresc...@adobe.com>
Subject Re: JSOP
Date Wed, 30 Nov 2011 13:35:41 GMT
On 30.11.2011 14:20, Thomas Mueller wrote:
> Hi,
>
>> If the task is "define a patch format for use over HTTP Patch", then
>> yes, we can assume HTTP is there.
>
> Yes. But for Jackrabbit 3, we want to define an API that doesn't require
> HTTP (or ZIP). Currently it's a Java API, but we might extend it to other
> programming languages such a PHP, C#, and C.

Are we defining a protocol or an API? My understanding was that we're 
talking about a remoting protocol that, yes, should use HTTP.

If the microkernel work has adopted a certain building block (a diff 
format) that's fine, but it shouldn't mean that this work should drive 
the definition of the protocol (which is something we would commit to 
support for remote access for a long time).

>> We still suffer from an agreed-upon set of design goals and constraints.
>
> In my view, the goal is to standardize a format that supports the features
> required by the current use cases. Probably the most advanced use case is
> the Jackrabbit 3 MicroKernel API. Also, the features required by the
> MicroKernel API should be supported. The format can't rely on a HTTP
> binding.

It seems to me then that we're talking about different things.

>> If we want to *standardize* something, we need to abstract away things
>> specific to JCR.
>
> The standard must not refer to JCR, but the standard should support the
> features required by JCR. Is this what you mean if you write "abstract
> away"?

With "abstract away" I meant: we need to map JCR features to generic 
things, like addressing JCR nodes through HTTP (so that we have things 
we can apply GET, PUT, PATCH to) and mapping JCR node trees to JSON (so 
that having a patch format for JSON is something we can actually apply 
to our remoting cases).

>> Also, we need either to get the features we need into
>> the common formats (such as support for tagging batches or adding
>> tests), *or* need to make sure extension points are in place.
>
> I agree. Extension points could be documented as optional features.

Actually, the *extension point* needs to be required, in that recipients 
do not fail when it is used. Which brings us to must-understand vs 
must-ignore.

Best regards, Julian

Mime
View raw message