[jr3 http api as a first class citizen]

[Christian Stocker <ch...@liip.ch>]

Hi

It would be great if in JR3 all JCR methods would be exposed to a HTTP
(REST) API. Currently the most important stuff is, but not everthing.
And some things just needs too many roundtrips, so some shortcuts to the
official JCR way would be nice too.

Just wanted to mention that, as it's really important for initiatives
like Jackalope

Greetings

chregu

Re: [jr3 http api as a first class citizen]

[Justin Edelson <ju...@justinedelson.com>]

On Feb 23, 2012, at 9:36 AM, Christian Stocker <ch...@liip.ch> wrote:

> 
> 
> On 23.02.12 15:26, Thomas Mueller wrote:
> 
> 
>> 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.

May I ask why not? If it is not part of JSR 333, it seems to me it is unlikely to be a complete mapping of the API. 

Justin
> 
> 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
> 

Re: [jr3 http api as a first class citizen]

[Christian Stocker <ch...@liip.ch>]

On 24.02.12 08:18, Thomas Mueller wrote:
> Hi,
> 
>> 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.
> 
> Yes, this is one of the goals for Jackrabbit 3. Remoting over HTTP is very
> important. The current plan is to support two kinds of remoting.

Great. Thanks for the update and that is actually all I wanted to make
sure. But you already had that in your plans, which makes me very happy.

Also saw https://wiki.apache.org/jackrabbit/Jsop now, looks interesting

chregu

> 
> * The first and most important is the remoting on the high-level
> Jackrabbit API (high level functionality, but the transient space is on
> the client). This includes functionality like versioning. This will be
> standardized. 
> 
> * The second kind of remoting might not be exposed at all, it is the
> MicroKernel remoting. It's used on a lower level, to remote low level
> MicroKernel API calls. The idea is to use it for virtual repositories and
> clustering. There is an implementation available already in the sandbox.
> 
> Possibly (this is highly controversial) the high-level remoting will be
> just a superset of the low-level remoting, for example by defining
> additional semantics to the path and the data.
> 
>> I'd gladly help, whenever I can, my java skills are just not really up
>> to what's needed here.
> 
> We need to document the protocol, the semantics of the transferred data,
> and examples. No Java skills required :-)
> 
> 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

Re: [jr3 http api as a first class citizen]

[Thomas Mueller <mu...@adobe.com>]

Hi,

>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.

Yes, this is one of the goals for Jackrabbit 3. Remoting over HTTP is very
important. The current plan is to support two kinds of remoting.

* The first and most important is the remoting on the high-level
Jackrabbit API (high level functionality, but the transient space is on
the client). This includes functionality like versioning. This will be
standardized. 

* The second kind of remoting might not be exposed at all, it is the
MicroKernel remoting. It's used on a lower level, to remote low level
MicroKernel API calls. The idea is to use it for virtual repositories and
clustering. There is an implementation available already in the sandbox.

Possibly (this is highly controversial) the high-level remoting will be
just a superset of the low-level remoting, for example by defining
additional semantics to the path and the data.

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

We need to document the protocol, the semantics of the transferred data,
and examples. No Java skills required :-)

Regards,
Thomas

Re: [jr3 http api as a first class citizen]

[Christian Stocker <ch...@liip.ch>]

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

Re: [jr3 http api as a first class citizen]

[Felix Meschberger <fm...@adobe.com>]

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.

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
> 

Re: [jr3 http api as a first class citizen]

[Christian Stocker <ch...@liip.ch>]

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.


> 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

Re: [jr3 http api as a first class citizen]

[Thomas Mueller <mu...@adobe.com>]

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?

For performance, the transient space should be on the client, so it would be batch operations, and not directly mapping JCR methods calls, right?

I don't think this will be part of JCR-333, but probably another standard (JSOP).

Regards,
Thomas

Re: [jr3 http api as a first class citizen]

[Justin Edelson <ju...@justinedelson.com>]

IMHO, this is something the JSR-333 should be defining.

Justin
On Feb 23, 2012 1:46 AM, "Christian Stocker" <ch...@liip.ch>
wrote:

> Hi
>
> It would be great if in JR3 all JCR methods would be exposed to a HTTP
> (REST) API. Currently the most important stuff is, but not everthing.
> And some things just needs too many roundtrips, so some shortcuts to the
> official JCR way would be nice too.
>
> Just wanted to mention that, as it's really important for initiatives
> like Jackalope
>
> Greetings
>
> chregu
>