Hi,
Am 29.02.2012 um 08:55 schrieb Thomas Mueller:
Hi,
I think we all have more or less the same basic idea. Well, I would call
it Node and not Tree because the term node more closely matches what
we do. But first about what we seem to agree:
* A persistent and immutable data structure
Hi,
Am 29.02.2012 um 08:57 schrieb Thomas Mueller:
Hi,
As has been said other places: Requiring a wrapper indicates a general
issue with the API...
No. We do need two interfaces:
* A stringly typed one for C and for remoting
C has struct and remoting is an implementation detail.
Hi,
* Mutable data strucutures also have benefits:
it avoids creating lots of garbage and a new root node
for each and every modification.
I don't really care for garbage: In fact Java is even better at
allocating and cleaning up short-lived small objects than C is.
Well, it's also about
Hi,
Am 29.02.2012 um 09:26 schrieb Thomas Mueller:
As a user of the JCR API I really do care about concurrent writes.
We discussed that at the F2F. It seems your problem is actually write
throughput. You *think* that concurrent writes will automatically improve
write throughput. Well, this
Hi,
I don't want to be nitpicking and whatever implementation you come up
with to help my concurrent write use case is fine with me.
Could you describe your concurrent write use case then please? A test
case would be best.
Write throughput will also decrease if data structures are
always
Hi,
Am 29.02.2012 um 09:36 schrieb Thomas Mueller:
Hi,
I don't want to be nitpicking and whatever implementation you come up
with to help my concurrent write use case is fine with me.
Could you describe your concurrent write use case then please? A test
case would be best.
I don't have
Hi,
I don't have a real test case. But assume this:
* 50 people updating content (in different areas of the tree)
* another 100 people reading from the repository
* digital asset import with workflow processing (involving repository
updates, too).
OK, I see what you mean with
I'd solve this differently. Saves are always performed on one partition,
even if some of the change set actually goes beyond a given partition.
this is however assuming that our implementation supports dynamic
partitioning and redistribution (e.g. when a new cluster node is added
to the
Hi,
On 29.2.12 6:31, Jukka Zitting wrote:
Hi,
On Wed, Feb 29, 2012 at 1:54 AM, Michael Dürigmdue...@apache.org wrote:
See https://gist.github.com/1934912 for what I meant about factoring
mutability out for transient modifications into a decorator on top of a
completely immutable (i.e.
As has been said other places: Requiring a wrapper indicates a general
issue with the API...
No. We do need two interfaces:
* A stringly typed one for C and for remoting
Not sure. If we don't plan to make this a public API, why do we care so
much then?
* An object-oriented one for
Hi,
On Feb 28, 2012, at 3:54 PM, Marcel Reutegger wrote:
I'd solve this differently. Saves are always performed on one
partition,
even if some of the change set actually goes beyond a given partition.
this is however assuming that our implementation supports dynamic
partitioning and
Hi,
On Tue 28, 2012, at 6:32 PM, Michael Dürig wrote:
On 28.2.12 15:40, Thomas Mueller wrote:
One reason to use the MicroKernel API is so we can implement a native
version of the MicroKernel. See also
http://wiki.apache.org/jackrabbit/Goals%20and%20non%20goals%20for%20Jackrab
bit%203 - TBD -
On Wed, Feb 29, 2012 at 12:01 AM, Jukka Zitting jukka.zitt...@gmail.com wrote:
Hi,
On Tue, Feb 28, 2012 at 6:21 PM, Jukka Zitting jukka.zitt...@gmail.com
wrote:
I guess you'd agree that the MicroKernel API covers a lot more
functionality than the Tree/Leaf interfaces I drafted. Someone
Hi,
On Feb 28, 2012, at 3:54 PM, Marcel Reutegger wrote:
I'd solve this differently. Saves are always performed on one
partition,
even if some of the change set actually goes beyond a given partition.
this is however assuming that our implementation supports dynamic
partitioning and
On 29.2.12 13:52, Marcel Reutegger wrote:
Hi,
On Feb 28, 2012, at 3:54 PM, Marcel Reutegger wrote:
I'd solve this differently. Saves are always performed on one
partition,
even if some of the change set actually goes beyond a given partition.
this is however assuming that our implementation
On Wed, Feb 29, 2012 at 8:55 AM, Thomas Mueller muel...@adobe.com wrote:
Hi,
I think we all have more or less the same basic idea. Well, I would call
it Node and not Tree because the term node more closely matches what
we do. But first about what we seem to agree:
* A persistent and
Vector clocks. See the presentation [1] which I prepared for the last F2F.
I understand this would require tagging each node with a timestamp, right?
If that's the case, then it's not just about complexity, but also additional
storage requirements.
regards
marcel
Hi,
While I agree MVCC and clustering are important, but I came to the
conclusion that those do not require a content addressable storage.
svn and git.
My implementation is modeled after relational and NoSQL databases.
Databases are optimized for fine grained content (rows), which I believe
Hi,
On Feb 29, 2012, at 2:52 PM, Marcel Reutegger wrote:
Hi,
On Feb 28, 2012, at 3:54 PM, Marcel Reutegger wrote:
I'd solve this differently. Saves are always performed on one
partition,
even if some of the change set actually goes beyond a given
partition.
this is however assuming that
On 29.2.12 15:45, Marcel Reutegger wrote:
Vector clocks. See the presentation [1] which I prepared for the last F2F.
I understand this would require tagging each node with a timestamp, right?
If that's the case, then it's not just about complexity, but also additional
storage requirements.
On Feb 29, 2012, at 5:45 PM, Michael Dürig wrote:
That's an idea I mentioned earlier already [1]: make cluster sync
transparent to JCR sessions. That is, any modification required by the
sync, should look like just another session operation to JCR clients
(i.e. there should also be observation
21 matches
Mail list logo
