On Jun 28, 2012, at 01:24 , Jukka Zitting wrote:
Hi,
On Wed, Jun 27, 2012 at 6:31 PM, Lukas Kahwe Smith m...@pooteeweet.org
wrote:
i assume this session space will not cause duplicating the rest of the
workspace
content that hasnt changed, right?
Right. No physical duplication of
Hi,
Am 28.06.2012 um 01:15 schrieb Jukka Zitting:
do you envision oak-jcr being a client of this http binding?
No, we already have the Oak API for that.
How about remotely located oak-jcr installs ?
As in: oak-jcr on box X talking to oak-core on box Y. This should probably be
able to
On Thu, Jun 28, 2012 at 1:15 AM, Jukka Zitting jukka.zitt...@gmail.com wrote:
Hi,
On Wed, Jun 27, 2012 at 6:49 PM, Stefan Guggisberg
stefan.guggisb...@gmail.com wrote:
well, statements like the following lead me to this assumption:
OK, I can see how I could have given such an impression.
On Thu, Jun 28, 2012 at 11:16 AM, Jukka Zitting jukka.zitt...@gmail.com wrote:
Hi,
On Thu, Jun 28, 2012 at 9:07 AM, Felix Meschberger fmesc...@adobe.com wrote:
How about remotely located oak-jcr installs ?
As in: oak-jcr on box X talking to oak-core on box Y. This should probably
be able
hi jukka
makes a lot of sense to me and pretty matches the goal of he
whole JSOP approach.
there is just one thing i don't feel totally comfortable with:
By default the HTTP binding could simply use a fresh new session for
each HTTP request, but it should be possible for a client to request a
Hi,
Am 27.06.2012 um 11:20 schrieb Jukka Zitting:
Hi,
On Wed, Jun 27, 2012 at 10:25 AM, Angela Schreiber anch...@adobe.com wrote:
i don't fully see the use case for such long living sessions.
FWIW, this was my first thought, too: This completely breaks stateless-ness of
HTTP and
Hi,
On Wed, Jun 27, 2012 at 11:49 AM, Felix Meschberger fmesc...@adobe.com wrote:
FWIW, this was my first thought, too: This completely breaks stateless-ness
of HTTP and introduces the use of Sessions.
I think you're misreading the proposal. The feature uses separate URI
spaces so all
Hi,
Am 27.06.2012 um 12:13 schrieb Jukka Zitting:
Hi,
On Wed, Jun 27, 2012 at 11:49 AM, Felix Meschberger fmesc...@adobe.com
wrote:
FWIW, this was my first thought, too: This completely breaks stateless-ness
of HTTP and introduces the use of Sessions.
I think you're misreading the
On 27.6.12 12:50, Felix Meschberger wrote:
Hi,
Am 27.06.2012 um 12:13 schrieb Jukka Zitting:
Hi,
On Wed, Jun 27, 2012 at 11:49 AM, Felix Meschberger fmesc...@adobe.com wrote:
FWIW, this was my first thought, too: This completely breaks stateless-ness
of HTTP and introduces the use of
Hi,
I understand the point Felix is making. As of now, I would propose to drop
separate URI spaces.
I would also propose to drop the related MicroKernel branch/merge feature,
or at least not rely on the feature to be available. In my view, the
MicroKernel branch/merge feature which was
Hi,
Am 27.06.2012 um 13:49 schrieb Michael Dürig:
On 27.6.12 12:50, Felix Meschberger wrote:
Hi,
Am 27.06.2012 um 12:13 schrieb Jukka Zitting:
Hi,
On Wed, Jun 27, 2012 at 11:49 AM, Felix Meschberger fmesc...@adobe.com
wrote:
FWIW, this was my first thought, too: This completely
On Wed, Jun 27, 2012 at 11:20 AM, Jukka Zitting jukka.zitt...@gmail.com wrote:
Hi,
On Wed, Jun 27, 2012 at 10:25 AM, Angela Schreiber anch...@adobe.com wrote:
i don't fully see the use case for such long living sessions.
The rationale is the same as for the branch feature we added to the
On Wed, Jun 27, 2012 at 11:49 AM, Felix Meschberger fmesc...@adobe.com wrote:
Hi,
Am 27.06.2012 um 11:20 schrieb Jukka Zitting:
Hi,
On Wed, Jun 27, 2012 at 10:25 AM, Angela Schreiber anch...@adobe.com wrote:
i don't fully see the use case for such long living sessions.
FWIW, this was my
Hi,
On Wed, Jun 27, 2012 at 12:50 PM, Felix Meschberger fmesc...@adobe.com wrote:
Its not about shared state but about state maintained on the server which
means
the exchange is not stateless any longer.
I don't follow this argument; the entire repository is one big piece
of server-side
hi stefan
i thought that we have a consensus of how the oak stack should be layered, i.e.
that was my understanding as well
app / sling / oak-jcr (trans. space) / [remoting /] oak-core [remoting
/] oak-mk.
or alternatively:
app / non-java-content-repo-api / [remoting/] oak-core
Hi,
On Wed, Jun 27, 2012 at 2:57 PM, Stefan Guggisberg
stefan.guggisb...@gmail.com wrote:
now your proposal seems to imply a different architecture...
You're reading far too much into this. I'm just thinking of exposing a
feature that seems like it could come in handy for some potential
Hi,
Ah ! Sounds much better now. Thanks alot for the clarification.
So
$ curl -X DELETE http://localhost:8080/branch/X
would in fact drop the branch, right ?
Regards
Felix
Am 27.06.2012 um 15:00 schrieb Jukka Zitting:
Hi,
On Wed, Jun 27, 2012 at 12:50 PM, Felix Meschberger
Hi,
On Wed, Jun 27, 2012 at 4:02 PM, Felix Meschberger fmesc...@adobe.com wrote:
Ah ! Sounds much better now. Thanks alot for the clarification.
So
$ curl -X DELETE http://localhost:8080/branch/X
would in fact drop the branch, right ?
Indeed.
BR,
Jukka Zitting
Hi
On 27.06.12 15:07, Jukka Zitting wrote:
Hi,
On Wed, Jun 27, 2012 at 2:57 PM, Stefan Guggisberg
stefan.guggisb...@gmail.com wrote:
now your proposal seems to imply a different architecture...
You're reading far too much into this. I'm just thinking of exposing a
feature that seems
Hi,
On Mon, Jun 25, 2012 at 2:26 PM, Jukka Zitting jukka.zitt...@gmail.com wrote:
As suggested in OAK-104 [1] and discussed briefly before, I think it
would be useful for Oak to have a native HTTP binding that allows
remote clients to talk directly with oak-core without having to go
through
On Wed, Jun 27, 2012 at 3:07 PM, Jukka Zitting jukka.zitt...@gmail.com wrote:
Hi,
On Wed, Jun 27, 2012 at 2:57 PM, Stefan Guggisberg
stefan.guggisb...@gmail.com wrote:
now your proposal seems to imply a different architecture...
You're reading far too much into this.
well, statements like
Hi,
On Wed, Jun 27, 2012 at 6:49 PM, Stefan Guggisberg
stefan.guggisb...@gmail.com wrote:
well, statements like the following lead me to this assumption:
OK, I can see how I could have given such an impression. Sorry about
the poor wording. With clients in this context I meant just the
clients
Hi,
On Wed, Jun 27, 2012 at 6:31 PM, Lukas Kahwe Smith m...@pooteeweet.org wrote:
i assume this session space will not cause duplicating the rest of the
workspace
content that hasnt changed, right?
Right. No physical duplication of content takes place.
if we also make it possible to sync
Hi,
On Mon, Jun 25, 2012 at 2:26 PM, Jukka Zitting jukka.zitt...@gmail.com wrote:
By default the HTTP binding could simply use a fresh new session for
each HTTP request, but it should be possible for a client to request a
longer-lived session for more complex content modifications (import,
Hi
We're from PHPCR and Jackalope are of course very interested in those
HTTP bindings and would love to play with them and see if it fits our
needs and give you more input. You're suggestions below seem to make
sense to me.
Greetings
chregu
On 25.06.12 14:26, Jukka Zitting wrote:
Hi,
As
25 matches
Mail list logo
