Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Received-SPF: pass (nike.apache.org: domain of fmeschbe@gmail.com designates
 209.85.220.221 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:user-agent:mime-version:to:subject:references
         :in-reply-to:content-type:content-transfer-encoding;
        b=o+hn/sQkzxLFoWHzQNqjSEWH/FrUEg7Pm7iQcV4lQ12D7pE9tKhOq0MNEOqjTlFMii
         U1knr73dXChUNv79Qg9+wKQbQBWxfT/7fWYKly99N6+MjSpmo5ryqFRcHb4y3fb8lTMn
         0413oHVUZlrzvvwMjJW5p0u/CamVJOoJjhcto=
Message-ID: <4BA0C79D.6050306@gmail.com>
Date: Wed, 17 Mar 2010 13:14:21 +0100
From: Felix Meschberger <fmeschbe@gmail.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
 rv:1.9.1.8pre) Gecko/20100120 Shredder/3.0.2pre
MIME-Version: 1.0
To: dev@jackrabbit.apache.org
Subject: Re: [jr3] MicroKernel prototype
References: <91f3b2651003150500k670b3734p50cadad418a6ffad@mail.gmail.com>
	 <91f3b2651003161146o195a4e53o872fdb0aa0aa9cd6@mail.gmail.com>
	 <4BA0AB22.5070803@gmail.com>
 <91f3b2651003170419l5f6cfa45ib36f53be5b92ef62@mail.gmail.com>
In-Reply-To: <91f3b2651003170419l5f6cfa45ib36f53be5b92ef62@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi,

On 17.03.2010 12:19, Thomas M=C3=BCller wrote:
> Hi,
>=20
>> premature optimization
>=20
> Sure, premature optimization should be avoided. But sometimes you need
> to validate that a certain architecture / algorithm doesn't result in
> very slow or unmaintainable code. I mean, that's the reason to write a
> prototype: so you can actually test it.
>=20
>> clean and easy to understand architecture
>=20
> Yes, make it as easy as possible. For example, I didn't implement a
> CachingHierarchyManager. I was a bit afraid it will be a problem, but
> it looks like it's not. That's good.
>=20
>> loose weight
>=20
> You probably mean "speed up".

Yeah, took the liberty of using a metaphor ;-)

On the other hand, removing unneeded, duplicate code is also something
worth while...

> Yes, it's almost always possible to
> improve performance a bit by tweaking the implementation. But it's
> usually very hard to "remove code" after it has been added and used.

Depends. If you use proper encapsulation separating public and private
parts, you are completely free restructuring the private part - as long
as you stick with the general contract ...

This is why I am so keen on separating internal and external parts ! Its
expensive to begin with but gives far more freedom afterwards.

>=20
>> the prototype currently probably misses tasks that Jackrabbit currentl=
y does
>=20
> Sure. But I don't know any that would account for big performance or
> architectural problems. Shareable nodes was one such case (without
> shareable nodes the prototype wouldn't need NodeState).
>=20
>> data validation against the node types
>=20
> Nobody uses node types. Just joking. The test case doesn't use node
> types so I don't think this is the reason why the prototype is so much
> faster. But there might be other things I forgot.

Well, ehrm, unless Jackrabbit handles "nt:unstructured" specially, you
*always* use node types ;-)

Regards
Felix