jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Stocker <christian.stoc...@liip.ch>
Subject Re: [jr3 http api as a first class citizen]
Date Thu, 23 Feb 2012 17:35:15 GMT


On 23.02.12 16:05, Felix Meschberger wrote:
> Hi,
> 
> Am 23.02.2012 um 15:36 schrieb Christian Stocker:
> 
>>
>>
>> On 23.02.12 15:26, Thomas Mueller wrote:
>>> Hi,
>>>
>>>    It would be great if in JR3 all JCR methods would be exposed to a HTTP
>>>    (REST) API.
>>>
>>>
>>> +1
>>>
>>>    Currently the most important stuff is, but not everthing.
>>>
>>>
>>> Could you provide some examples what is not there yet?
>>
>> This https://issues.apache.org/jira/browse/JCR-2003 is a pretty complete
>> list.
> 
> Hmm, this reads like "remoting over HTTP". This is not really REST in my book.

Don't take that (REST) above at face value. Yes, it's more about the
"remoting over HTTP" than the REST part. I think the way it's done now
over WebDav(extended) isn't that bad of an approach (for our purposes).
Some improvements here and there for easier performance optimization on
the client side (I can't tell you those right now but I'm sure we can
come up with a list) and the almost complete exposure of the
possibilities of JR3 via that HTTP interface would help us a lot.

What I basically wanted to say is, that nowadays the HTTP interface
feels like "just" an addition and some features are not exposed at all.
It would be great if that would change for JR3 where every method (which
makes sense) is also exposed to an HTTP interface from the beginning. I
guess this would also make JR3 and the whole JCR idea much more
appealing to people outside of the Java world.

I'd gladly help, whenever I can, my java skills are just not really up
to what's needed here.

Greetings

chregu



> 
> Regards
> Felix
> 
>>
>>
>>> For performance, the transient space should be on the client, so it
>>> would be batch operations, and not directly mapping JCR methods calls,
>>> right?
>>
>> Not sure what exactly you mean. For saving stuff, yes, the transient
>> space is on the client side and we batch them on save. But we still need
>> somehow a way to map all JCR methods to PHPCR (the JCR for PHP). How
>> that's done on the HTTP level doesn't really matter, as long as it's
>> somehow possible.
>>
>> Currently it seems that the HTTP "API" is just an afterthought and
>> therefore sometimes neglected. It would be great if that would be
>> different in JR3. Like in other newer approaches lately, eg. in couchdb
>> (that's just the example which popped up in my mind, I'm not saying,
>> that's a perfect example :))
>>
>>
>>> I don't think this will be part of JCR-333, but probably another
>>> standard (JSOP).
>>
>> I don't see this going into JSR-333 either.
>>
>> Greetings
>>
>> chregu
>>
>>> Regards,
>>> Thomas
>>
>> -- 
>> Liip AG  //  Feldstrasse 133 //  CH-8004 Zurich
>> Tel +41 43 500 39 81 // Mobile +41 76 561 88 60
>> www.liip.ch // blog.liip.ch // GnuPG 0x0748D5FE
>>

-- 
Liip AG  //  Feldstrasse 133 //  CH-8004 Zurich
Tel +41 43 500 39 81 // Mobile +41 76 561 88 60
www.liip.ch // blog.liip.ch // GnuPG 0x0748D5FE


Mime
View raw message