What I do worry though, and why I did bring this up in the first
place, is that the API being defined ends up being as easy and
straightforward to use for key clients, as that's a major part in
deciding whether the API is successful or not. Personally, with the
assumption that I'll be writing nota
Hi,
On Tue, Jun 21, 2011 at 11:45 AM, Thomas Mueller wrote:
> Otherwise the discussion is essentially hot air against hot air.
Agreed on the performance part. More notably, I'd say that the
performance or memory overhead of JSON vs. noJSON is pretty much
irrelevant when compared to the disk or n
Hi,
>Sounds like a theoretical discussion doesn't help here, only
>performance/resource usage comparisons can prove those differences.
Yes, that's why we need to build the prototype :-) Which we can then
compare against other implementations (my J3 prototype, Jackrabbit).
Otherwise the discussio
On 21.06.11 09:13, "Thomas Mueller" wrote:
>>What about using the
>>json library in-memory representations for the microkernel to avoid
>>serialization/parsing if not necessary?
>
>How would that make parsing and serialization _not_ necessary?
That very much depends on what is happing on the clie
Hi,
>What about using the
>json library in-memory representations for the microkernel to avoid
>serialization/parsing if not necessary?
How would that make parsing and serialization _not_ necessary?
Currently, the MicroKernel doesn't fully parse the Json - it just splits
the Json diff into token
On 20.06.11 15:22, "Thomas Mueller" wrote:
>>This is actually the way I's prefer to go.
>
>Me too - otherwise, I wouldn't have implemented those classes :-)
>Val.toString() returns Json by the way.
If json provides the right amount of (standardized) unstructuredness I
guess it's useful (and can b
Hi,
>This is actually the way I's prefer to go.
Me too - otherwise, I wouldn't have implemented those classes :-)
Val.toString() returns Json by the way.
>Define representations of
>commonly used entities (Value, Node, Property...) which can be easily
>used across the stack.
When implementing m
I did implement low level 'value' and 'bundle' classes, which could be
used by both the client and the MicroKernel:
org.apache.jackrabbit.j3.mc.Val
org.apache.jackrabbit.j3.mc.Bundle
This is actually the way I's prefer to go. Define representations of
commonly used entities (Value, Node, Pro
On Mon, Jun 20, 2011 at 12:43 PM, Michael Dürig wrote:
>
>> agreed. since the audience of the MicroKernel API is pretty small
>> programmer-friendliness has admittedly not been a top priority ;)
>
> I think programmer-friendliness should have a higher priority then. Where
> did this priorities com
Hi,
>The MicroKernel implementation has to parse and reserialize JSON
>strings whenever it needs to process a diff or is given a nonstandard
>set of depth, offset and count values in a getNodes() call.
Currently, the MicroKernel doesn't really parse the Json in this case. It
only tokenizes the di
Hi,
On Mon, Jun 20, 2011 at 12:50 PM, Thomas Mueller wrote:
> Only if the implementation needs to do anything with the values (except
> for storing and retrieving). The MicroKernel doesn't care about most of
> the values - they are just stored "as is".
The MicroKernel implementation has to parse
2) The complexity of the API: this is a *a lot* simpler than the SPI.
You are mixing things up here. The SPI interfaces cope with versioning,
access rights, search, workspaces, name spaces, node types, import,
locking and observation. All of which is not present in the micro
kernel. That's wh
Hi,
>>why JSON strings?
>> - easy portability
>> - remoting-friendly
>> - leads to very compact API
>> - JSON parsing/generating overhead is IMO minimal
>>and probably more effecient than creating (and collecting) tons of
>>small java objects on the heap
>>
>
>I doubt this. In fact I think
On 20.6.11 12:36, Stefan Guggisberg wrote:
On Mon, Jun 20, 2011 at 12:21 PM, Michael Dürig wrote:
why JSON strings?
- easy portability
- remoting-friendly
- leads to very compact API
- JSON parsing/generating overhead is IMO minimal
and probably more effecient than creating (and collecti
agreed. since the audience of the MicroKernel API is pretty small
programmer-friendliness has admittedly not been a top priority ;)
I think programmer-friendliness should have a higher priority then.
Where did this priorities come from btw?
Programmer unfriendly api's lead to programmers de
On Mon, Jun 20, 2011 at 12:21 PM, Michael Dürig wrote:
>
>> why JSON strings?
>> - easy portability
>> - remoting-friendly
>> - leads to very compact API
>> - JSON parsing/generating overhead is IMO minimal
>> and probably more effecient than creating (and collecting) tons of
>> small java obj
why JSON strings?
- easy portability
- remoting-friendly
- leads to very compact API
- JSON parsing/generating overhead is IMO minimal
and probably more effecient than creating (and collecting) tons of
small java objects on the heap
I doubt this. In fact I think the situation with the s
Hi,
>To me it seems like the JSON parts of the API would be better suited
>for a higher-level integration layer.
What other API do you suggest, and why/how would it be better than JSON? A
few advantages of using JSON:
1) Loose coupling: the MicroKernel doesn't have to know all the details
about
On Sun, Jun 19, 2011 at 3:15 PM, Jukka Zitting wrote:
> Hi,
>
> On Fri, Jun 17, 2011 at 6:37 PM, Stefan Guggisberg
> wrote:
>> one of the design goals of the MicroKernel API was "easy portablilty".
>> typically it would be used in-proc by some higher level code, comparable
>> to the current SPI.
Hi,
On Fri, Jun 17, 2011 at 6:37 PM, Stefan Guggisberg
wrote:
> one of the design goals of the MicroKernel API was "easy portablilty".
> typically it would be used in-proc by some higher level code, comparable
> to the current SPI.
To me it seems like the JSON parts of the API would be better su
sorry for being late...
On Fri, Jun 10, 2011 at 1:18 PM, Jukka Zitting wrote:
> Hi,
>
> On Wed, May 11, 2011 at 6:31 PM, Stefan Guggisberg
> wrote:
>> as some of you may have noticed i've started work on my own
>> MicroKernel proposal a while ago in the jackrabbit sandbox.
>>
>> although the pro
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
hi,
with the jackalope project, we implement a php binding for jcr that
talks over the spi connection to the jackrabbit backend.
talking to the microkernel over REST would be the natural evolution of
things - the closer to the current spi the better
Hi,
>Sure. I'm just questioning whether the benefits of a custom
>implementation really are worth the time spent reinventing the wheel
>and fixing all the inevitable bugs.
Yes. In fact, I believe it is actually much better to re-write the few
JSON specific methods we need than trying to cobble to
Hi,
On Fri, Jun 10, 2011 at 3:13 PM, Thomas Mueller wrote:
> This is similar to 'why do you build your own SQL-2 parser and don't use
> Lex/Flex/Yacc/Javacc/ANTLR/other parser tool', or 'why do you build your
> own cache and don't use Ehcache/other cache libary', or 'why do you build
> your own (
Hi,
>Why would we ever want to build our own JSON parsing and serialization
>code? Just use one of the existing libraries out there.
This is similar to 'why do you build your own SQL-2 parser and don't use
Lex/Flex/Yacc/Javacc/ANTLR/other parser tool', or 'why do you build your
own cache and don'
Hi,
On Fri, Jun 10, 2011 at 1:41 PM, Michael Dürig wrote:
>> Another question: Why would we ever want to build our own JSON parsing
>> and serialization code? Just use one of the existing libraries out
>> there.
>
> One of the reasons is that we are not strictly JSON. i.e. order of the items
> is
Hi,
Another question: Why would we ever want to build our own JSON parsing
and serialization code? Just use one of the existing libraries out
there.
One of the reasons is that we are not strictly JSON. i.e. order of the
items is of importance.
Michael
Hi,
On Wed, May 11, 2011 at 6:31 PM, Stefan Guggisberg
wrote:
> as some of you may have noticed i've started work on my own
> MicroKernel proposal a while ago in the jackrabbit sandbox.
>
> although the project is in a very early stage i wanted to share my work
> with you.
Good stuff! I see peop
Hi,
I started working on an in-memory implementation of the API. This should
be useful for testing. I copied some of the code from my jackrabbit-j3
prototype.
Regards,
Thomas
On 5/11/11 6:31 PM, "Stefan Guggisberg"
wrote:
>hi,
>
>as some of you may have noticed i've started work on my own
>
Interesting... I expect to have a couple of hours to give a try.
El 11/05/2011 18:31, "Stefan Guggisberg"
escribió:
30 matches
Mail list logo
