Hi,
To address 1) I suggest we define a set of clear cut cases where any
Microkernel implementations MUST merge. For the other cases I'm not sure
whether we should make them MUST NOT, SHOULD NOT or MAY merge.
I agree and I think three cases are sufficient. MUST, MUST NOT and MAY.
MUST is for
Hi,
Just remember that MAY is difficult to handle by developers: Can I depend on
it or not ? What if the MAY feature does not exist ? What if I develop on an
implementation providing the MAY feature and then running on an
implementation not providing the MAY feature ?
In essence, a MAY
Agree with Felix, we should stay away from MAY especially if we want to achieve
clarity for Oak-Core what it can expect the MK to do
On Dec 18, 2012, at 9:49 AM, Felix Meschberger wrote:
Hi,
Just remember that MAY is difficult to handle by developers: Can I depend
on it or not ? What if
Hi Simo,
On Mon, Dec 17, 2012 at 5:38 PM, Simone Tripodi
simonetrip...@apache.org wrote:
...I think we were not speaking about the same commons :P What I meant
is the java module[1] on SVN...
That's *jackrabbit* commons, what I was thinking of is *JCR* commons -
as AFAIU your utility only has
On 18.12.12 9:38, Thomas Mueller wrote:
What I suggest should be merged within the MicroKernel:
* Two sessions concurrently add different child nodes to a node (/test/a
and /test/b): this is merged as it's not really a conflict
* Two sessions concurrently delete different child nodes
On Wed, Dec 12, 2012 at 4:46 PM, Michael Dürig mdue...@apache.org wrote:
Hi,
Currently the Microkernel contract does not specify a merge policy but is
free to try to merge conflicting changes or throw an exception. I think this
is problematic in various ways:
1) Automatic merging may
Hi,
In addition it would be nice to annotate conflicts in some way. This is
quite easy to do and would allow upper layers to resolve conflicts based
on specific business logic. Currently we do something along these lines
with the AnnotatingConflictHandler [1] in oak-core.
Sure, that would make
This is a bit more complicated. In fact it is the other way around: if
two journal entries commute, the corresponding differences on the nodes
due not conflict regarding the definition I gave.
OTOH non conflicting changes could still lead to non commuting journal
entries and thus merging
On Tue, Dec 18, 2012 at 12:49 PM, Michael Dürig mdue...@apache.org wrote:
This is a bit more complicated. In fact it is the other way around: if two
journal entries commute, the corresponding differences on the nodes due not
conflict regarding the definition I gave.
OTOH non conflicting
Hi,
On Mon, Dec 17, 2012 at 3:14 PM, Bertrand Delacretaz
bdelacre...@apache.org wrote:
What I see is http://jackrabbit.apache.org/commons/ which only
mentions jcr-rmi, and
http://svn.apache.org/repos/asf/jackrabbit/commons/ which has much
more than that - maybe the former needs to be updated
On 18.12.12 12:44, Stefan Guggisberg wrote:
On Tue, Dec 18, 2012 at 12:49 PM, Michael Dürig mdue...@apache.org wrote:
This is a bit more complicated. In fact it is the other way around: if two
journal entries commute, the corresponding differences on the nodes due not
conflict regarding the
On 18.12.12 11:30, Stefan Guggisberg wrote:
On Wed, Dec 12, 2012 at 4:46 PM, Michael Dürig mdue...@apache.org wrote:
Hi,
Currently the Microkernel contract does not specify a merge policy but is
free to try to merge conflicting changes or throw an exception. I think this
is problematic in
On Tue, Dec 18, 2012 at 2:30 PM, Michael Dürig mic...@gmail.com wrote:
On 18.12.12 11:30, Stefan Guggisberg wrote:
On Wed, Dec 12, 2012 at 4:46 PM, Michael Dürig mdue...@apache.org wrote:
Hi,
Currently the Microkernel contract does not specify a merge policy but is
free to try to merge
Hi,
1) Make the definition of conflicts sufficiently strong to exclude such
cases. That's Tom's proposal from this Thread.
Ah, OK, I thought you meant it could still be a problem even with my
proposal.
I guess failing on (node-level-) conflicts would be the most simple
solution, as a start. It
Hi,
2) Allow inconsistent journals.
I guess we don't want that. But the question is how close the journal
has
to match the original commit, specially move and copy operations. If
they need to be preserved (do they?), then it's complicated.
There is no use for a journal which is not accurate.
On 18.12.12 14:43, Thomas Mueller wrote:
Hi,
2) Allow inconsistent journals.
I guess we don't want that. But the question is how close the journal
has
to match the original commit, specially move and copy operations. If
they need to be preserved (do they?), then it's complicated.
There
Hi,
So, do move and copy operations need to be preserved, or can they be
converted to add node / remove node?
Now we are getting somewhere: This is exactly the original topic of
OAK-464. If the Microkernel converts moves to add/remove, implementing
rebase on top of that results in moves of big
On 2012-12-18 15:12, Tommaso Teofili wrote:
On 18/dic/2012, at 09:49, Felix Meschberger wrote:
Hi,
Just remember that MAY is difficult to handle by developers: Can I depend on it or not ? What if the
MAY feature does not exist ? What if I develop on an implementation providing the MAY
On 18.12.12 15:30, Stefan Guggisberg wrote:
On Tue, Dec 18, 2012 at 4:08 PM, Michael Dürig mdue...@apache.org wrote:
On 18.12.12 14:43, Thomas Mueller wrote:
Hi,
2) Allow inconsistent journals.
I guess we don't want that. But the question is how close the journal
has
to match the
Hi,
But the question is how close the journal has to match the original
commit, specially move and copy operations.
Yes. There are various degrees of how close the journal is to the commit.
One option is: the commit is preserved 1:1. The other extreme is: moves
are fully converted to add+remove.
In MongoMK, getJournal basically returns the jsonDiff from the commit, at
least in the simple case when there is no path to filter.
-Mete
On 12/18/12 4:57 PM, Thomas Mueller muel...@adobe.com wrote:
Hi,
But the question is how close the journal has to match the original
commit, specially move
On Tue, Dec 18, 2012 at 5:12 PM, Michael Dürig mdue...@apache.org wrote:
On 18.12.12 16:05, Mete Atamel wrote:
In MongoMK, getJournal basically returns the jsonDiff from the commit, at
least in the simple case when there is no path to filter.
And AFAIK this is the same for the H2 MK.
22 matches
Mail list logo
