Mailing-List: contact abdera-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: abdera-dev@incubator.apache.org
Received-SPF: pass (asf.osuosl.org: domain of rooneg@gmail.com designates
 66.249.92.169 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth;
        b=M03SPllajowBhVc+Tzb6QM+nCD5WelG0qOBHVCJV2/TRq3+ehBkL1OZypZBCNaUyv3QmxtKtbrxyptsNecvM5TEkbbI2AvX2YF4+Cli0u7HbGXDc+55JPXGM2eLkMvHEwvxDAZIeqcTYlkHAyUDEVQ8Ij79a+fgkcI+A6WyPDmE=
Message-ID: <7edfeeef0610181122i60f16fa0o686cae207068da30@mail.gmail.com>
Date: Wed, 18 Oct 2006 11:22:52 -0700
From: "Garrett Rooney" <rooneg@electricjellyfish.net>
Sender: rooneg@gmail.com
To: abdera-dev@incubator.apache.org
Subject: Re: Axiom
In-Reply-To: <4535A45F.2060509@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <4535A45F.2060509@gmail.com>

On 10/17/06, James M Snell <jasnell@gmail.com> wrote:

> At this point, so long as we maintain the incremental parse model,
> preserve the lightweight memory footprint, and can still support xml
> sigs and encryption, then I'm fine with moving away from Axiom.  Like I
> said, I could likely have something implemented in about two weeks.

I think there are a number of things Axiom is keeping us from
accomplishing, and that moving towards something else would probably
be a good idea.  Personally, I'm interested in the following goals:

  1) The ability to have extensions that don't peek into the parser
implementation.
  2) The ability to do async parsing (i.e. a getFirstSibling() on a
node would have the option of returning "nope, ain't got that data
yet".

Note that option 1 can naturally be made to go away by dropping the
concept of having multiple parser back ends.  I don't know if that's
something we want to do, but it might be.  I know that James has
mentioned the existence of alternate back ends within IBM, my real
question is what is the motivation for the existence of such things.
Are there problems they are trying to solve by using an alternate
parser that we could solve in our default?

Alternatively, we'd need our model to expose more information, so that
we can do things like "insert new node into the tree here" without
having to dip into the guts of the parser.  This would allow extension
nodes to live as full citizens alongside nodes that we create via the
parser.

Of those two goals, I'd say 1 is far more important than 2, but I do
think that 2 is worth thinking about.

If it's difficult or impossible to do this sort of thing with Axiom
(and I think they are impossible, from the investigations I made last
week), I'd be definately in favor of dropping it and moving on with
something else.

-garrett