jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Buchmann <david.buchm...@liip.ch>
Subject Re: [j3] Repository MicroKernel API draft
Date Thu, 16 Jun 2011 08:28:49 GMT
Hash: SHA1


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 :-)


Am 10.06.2011 16:54, schrieb Thomas Mueller:
> 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 together existing
> libraries with new code (trying to combine an existing JSON parser /
> builder with some self-written JSOP parser / generator), because that will
> inevitably lead to problems. It actually already does (see "TODO ugly
> hack", plus it's currently not possible to store the JSON as is without
> de-escaping).
>> My bigger concern here is that the JSON handling seems to be happening
>> at a way too low level.
> Yes, I'm working on this problem now. Please note it will still be
> necessary to parse the keys and some of the values. It is a low level to
> do that, and possibly we will end up replacing JSON with a binary format
> (such a BSON) if we find out it's really worth it (for performance or
> other reasons). But one advantage of using JSON (if nothing else) is that
> it's actually very easy to debug the code, which is very valuable at this
> stage.
>> both MicroKernelImpl
>> classes in o.a.j.mk and o.a.j.mk.mem duplicating pretty much the same
>> parsing and serialization logic. Can we refactor that code into a
>> single class/location?
> Sure, the plan is to merge that. I didn't want to overwrite Stefans code
> (at least not before I really understand it), that's why I didn't even try
> to merge things currently.
> Regards,
> Thomas

- -- 
Liip AG // Agile Web Development // T +41 26 422 25 11
CH-1700 Fribourg // PGP 0xA581808B // www.liip.ch
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/


View raw message