For everyone interested, I attached a first patch to OAK-2502. On that
issue you can also find a link to the branch in my GitHub fork where
I'm currently working.
2015-02-13 16:33 GMT+01:00 David Buchmann da...@liip.ch:
hi francesco,
in our offline meeting, we discussed revisions. i think the
hi francesco,
in our offline meeting, we discussed revisions. i think the generic
description should also mention the concept of the last revision. and
we had the idea that any read could report which revision the answer is
based on - this would allow to save one roundtrip to get the current
In an offline meeting today, it was noted that the specified handling
of binaries should be revised. Currently, any user is able to create
binary objects, even if those objects are never assigned as a value to
binary properties. This may open the (unwanted) possibility for the
repository to be
I created a couple of pages in the Jackrabbit wiki. The first [1] is
the generic description of the operations that you probably already
read, The second [2] is a draft of the REST API that exposes the
concepts exposed in [1] using HTTP as a transport protocol.
Any feedback is welcome.
[1]:
Hi,
I finally found some time to read your draft:
* what about large number of child nodes? I think we need some kind of
support for paging/chunking to avoid reading millions of children in one go.
* the write operations all fail if the operation has been done
already: E.g. the remove
On 23.1.15 6:09 , Francesco Mari wrote:
since I don't have access to the wiki, I started to write down a draft
for the remote API in a public GitHub repository [1].
Let me know the desired user name and I'll grant you access.
Michael
Hi,
I’m not sure if I have enough background to participate in the discussion,
so bear with me...
I think it wouldn’t be too hard to translate oak operations to an
HTTP-based API, if we just define some URLs as “special”, i.e. they don’t
represent the corresponding node in the repo but have
On 2015-02-02 15:33, Axel Hanikel wrote:
Hi,
I’m not sure if I have enough background to participate in the discussion,
so bear with me...
I think it wouldn’t be too hard to translate oak operations to an
HTTP-based API, if we just define some URLs as “special”, i.e. they don’t
represent the
On 2.2.15 3:33 , Axel Hanikel wrote:
Hi,
I’m not sure if I have enough background to participate in the discussion,
so bear with me...
I think it wouldn’t be too hard to translate oak operations to an
HTTP-based API, if we just define some URLs as “special”, i.e. they don’t
represent the
Aloha,
BTW .. I have not used their API but https://www.contentful.com/developers/ is
a content repository as a service. Not sure how they deal with concurrency and
multi step changes but maybe worth a look.
regards,
Lukas Kahwe Smith
sm...@pooteeweet.org
signature.asc
Description:
I am currently working on a REST API, that looks similar to what you
are proposing. I should have something to show really soon.
2015-02-02 15:33 GMT+01:00 Axel Hanikel ahani...@gmail.com:
Hi,
I’m not sure if I have enough background to participate in the discussion,
so bear with me...
I
I agree that a mechanism to cope with children is needed, other than
filtering by name.
I partially agree when you say that the end result of a single
operation can be either successful, skipped or failed. I am not really
sure if we need the skipped result, because a set of operations is
supposed
hi francesco,
On Fri, Jan 23, 2015 at 6:09 PM, Francesco Mari
mari.france...@gmail.com wrote:
Hi all,
since I don't have access to the wiki, I started to write down a draft
for the remote API in a public GitHub repository [1].
I didn't write much so far, but I invite every interested party
Which other alternatives do we have regarding authentication?
2015-01-27 9:16 GMT+01:00 Stefan Guggisberg stefan.guggisb...@gmail.com:
hi francesco,
On Fri, Jan 23, 2015 at 6:09 PM, Francesco Mari
mari.france...@gmail.com wrote:
Hi all,
since I don't have access to the wiki, I started to
On Tue, Jan 27, 2015 at 2:23 PM, Francesco Mari
mari.france...@gmail.com wrote:
My personal point of view is that the remote API should make Oak
interoperable between different software stacks. Some of these
software stacks may want to use their own authentication strategies
which may (or may
Should the API expose every authentication strategy implemented in
Oak? How is this API should look like?
2015-01-27 10:39 GMT+01:00 Stefan Guggisberg stefan.guggisb...@gmail.com:
On Tue, Jan 27, 2015 at 10:16 AM, Francesco Mari
mari.france...@gmail.com wrote:
Which other alternatives do we
My personal point of view is that the remote API should make Oak
interoperable between different software stacks. Some of these
software stacks may want to use their own authentication strategies
which may (or may not) be the authentication strategies provided by
Oak.
In a typical web
On Mon, Jan 26, 2015 at 12:38 PM, Francesco Mari
mari.france...@gmail.com wrote:
...Other people already applied this concept successfully with
the creation of the JSON Patch standard [1]
I wasn't aware of that upcoming standard, looks interesting indeed!
-Bertrand
[1]:
My reference to JSON Patch was not an indication that I recommend its
usage in this context, but it was more a counter-example to explain
that, in my opinion, JSOP doesn't add anything new to JSON if not
another notation that must be understood, parsed and supported -
potentially in non-Java
On 26.1.15 3:13 , Francesco Mari wrote:
3. enables horizontal scalability by eliminating state on the server.
I didn't follow all the communication yet as I'm on vacation. However I
think we can weaken this precondition to 3'. eliminating *transient*
state on the server. See
On 26 Jan 2015, at 15:13, Francesco Mari mari.france...@gmail.com wrote:
What you are proposing is a REST interface where every node can be
treated as an individual resource. This will not work. To fully
leverage the MVCC architecture of Oak, a set of related GET, POST, PUT
and DELETE
What you are proposing is a REST interface where every node can be
treated as an individual resource. This will not work. To fully
leverage the MVCC architecture of Oak, a set of related GET, POST, PUT
and DELETE requests must belong to the same context. This context, in
Oak, is represented by a
On Mon, Jan 26, 2015 at 10:28 AM, Francesco Mari
mari.france...@gmail.com wrote:
At the beginning I wanted to expose a more granular interface for node
operations, mapping every node to a fully REST resource
BTW, what happened to JSOP?
http://slideshare.net/uncled/jsop
-Bertrand
On 26 Jan 2015, at 11:07, Bertrand Delacretaz bdelacre...@apache.org wrote:
On Mon, Jan 26, 2015 at 10:28 AM, Francesco Mari
mari.france...@gmail.com wrote:
At the beginning I wanted to expose a more granular interface for node
operations, mapping every node to a fully REST resource
I think a multi-tree read request could be a good improvement to the
API. Technically speaking, it may be though as a generalization of the
Read tree operation.
2015-01-25 11:14 GMT+01:00 David Buchmann da...@liip.ch:
hi,
I started to write down a draft
for the remote API in a public GitHub
On 26 Jan 2015, at 09:55, Francesco Mari mari.france...@gmail.com wrote:
I think a multi-tree read request could be a good improvement to the
API. Technically speaking, it may be though as a generalization of the
Read tree operation.
can you elaborate why you are using an RPC style
At the beginning I wanted to expose a more granular interface for node
operations, mapping every node to a fully REST resource. I figured out
that this has some drawbacks.
First of all, you have to create some kind of context between HTTP
requests to guarantee that operations happen in your
On Mon, Jan 26, 2015 at 9:55 AM, Francesco Mari
mari.france...@gmail.com wrote:
...I think a multi-tree read request could be a good improvement to the
API...
In general, considering that you send a bunch of commands to the
server and get a bunch of corresponding responses back might help a
lot
The document I posted uses JSON only as a simple way to describe
generic data structures. There is a big disclaimer at the beginning of
operations.md. The operations are supposed to be described in an
abstract way, without any procol-dependent technology. Please, let's
evaluate operations.md
On 26 Jan 2015, at 12:04, Francesco Mari mari.france...@gmail.com wrote:
The document I posted uses JSON only as a simple way to describe
generic data structures. There is a big disclaimer at the beginning of
operations.md. The operations are supposed to be described in an
abstract way,
My point is that probably you don't need to extend a format when the
format you are extending is already powerful enough to express what
you need. Other people already applied this concept successfully with
the creation of the JSON Patch standard [1].
[1]: https://tools.ietf.org/html/rfc6902
+100 !
* Type=remove is exactly DELETE and we should do it
* type=add is just PUT or POST
* type=set likewise is just PUT or POST
* type=unset is exactly DELETE
So, please use those.
Regards
Felix
Am 26.01.2015 um 10:00 schrieb Lukas Kahwe Smith sm...@pooteeweet.org:
On 26 Jan 2015, at
Hi
Whether you use JSOP or RFC 6902 is essentially irrelevant. Maybe I tend to
slightly favour a standardised approach hence RFC 6902.
Regards
Felix
Am 26.01.2015 um 12:38 schrieb Francesco Mari mari.france...@gmail.com:
My point is that probably you don't need to extend a format when the
hi,
I started to write down a draft
for the remote API in a public GitHub repository [1].
I didn't write much so far, but I invite every interested party to
take a look at it for suggestions and improvements.
[1]: https://github.com/francescomari/oak-remote
looks good so me. we wrote a
Hi all,
since I don't have access to the wiki, I started to write down a draft
for the remote API in a public GitHub repository [1].
I didn't write much so far, but I invite every interested party to
take a look at it for suggestions and improvements.
Thanks,
Francesco
[1]:
35 matches
Mail list logo
