cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alan <>
Subject Re: Announce: Momento
Date Wed, 18 Feb 2004 18:07:58 GMT
* Stefano Mazzocchi <> [2004-02-18 14:02]:
> Alan wrote:
> >* Stefano Mazzocchi <> [2004-02-17 04:22]:
> >
> >>Alan wrote:
> >>
> >>
> >>>Momento is a native XML persistence engine. Is supports XSLT 2.0 and
> >>>  XQuery 1.0 (via Saxon), it supports XUpdate.

> >>Very interesting. Can you tell us more on how it works? have any numbers 
> >>on how fast/scalable it gets? what's the difference between Momento and 
> >>a native xml database like XIndice?

> >    3) I can't compare Momento to Xindice at the moment. Last I looked
> >    at Xindice was last November. I'm announcing to get such insight.
> >
> >        (I am willing to say that Momento isn't wedded to a specific
> >            API, such as XML::DB. It works with Saxon to provide
> >            XQuery and XSLT. 

> What is the interfacing API then? JAXP? or Saxon's?

JAXP. Standard APIs where possible.
    XUpdate is implemented as a SAX filter. Wrap the filter around a
    Momento document, put the filter in an XMLReader, feed XUpdate
    to the parse method of an XMLReader. 

> > I'm implementing XUpdate currently. A read-only W3 DOM is a
> > simple matter, if there is call for it. A read-write W3 DOM is
> > not so simple, or desireable, but entirely feasable.
> >            
> >            I could be way off base. Let me know.

> I'm not sure I get what you mean here with read/write DOM being desirable.

If there is a desire for a W3 DOM implementation that is read
    and write, it is feasable. It does not strike me as a good use
    of Momento. There is no interface to support transactions.

    The W3 DOM event model does make sense, however.

> >    2) No numbers. I've not designed any benchmarks. Momento is to the
> >    point where I need an example application to focus my energy to
> >    get Momento to beta. I was going to use Linotype, actually, and
> >    use Momento to store my blog.

> Uh, awesome!

A good initial application of Momento, I think. Brian McCallister
    has implemented an Atom feed. I say we put the three together.

> >    Towards scalablity Momento supports concurrent reads, and, with
> >    some educated decisions by the application developer, concurrent
> >    updates. 

> uh, this sentence is worrysome. Can you elaborate more?

What worries you? Momento asks the application developer to choose
    her clusters just as PostgreSQL asks her to chose her indicies.

> >    1) Momento has three concepts that rise to the surface when I
> >    consider it.
> >
> >        * Zero, I always forget that I spent a month writing a
> >          journaling file data structure. It just hums along quietly
> >          in the background now. It splits a random access file into
> >          pages. Reads those pages in and out of memory. It uses
> >          weak references to implement a page cache. It's pretty
> >          cool, but its pretty much done, so...
> uh, sounds useful. We are having problems with JISP. Care to tell us 
> more about this?

It is a journaled paged file structure. I built a record storage
    interface and a string storage interface using it. I built this
    out far enough to support Momento. It can do more.

    The key here is journalling. You can state that writes happen as
    an atomic transaction or not at all.

    No indicies though. Once Momento has an indicies, someone could
    use it as a basis for to replace JISP. Is JSIP ACID?

> >        * First, Momento maintains a version axis.
> >        
> >          The version-axis allows for however many concurrent
> >          queries, they will not have to wait for updates.
> Interesting approach. I don't see how you can do rollback if you garbage 
> collect a node, though.

Rollback means to rollback the current transcation. The state of the
    document prior to the current transaction is maintained on disk.

    I don't think I said "garbage" collect. Collection is in
    reference to collecting previous versions of the document on

> >         It makes sense to to cluster the issue nodes themselves
> >         together since the most likely axis of traversal is the the
> >         next-sibling axis, used to find a specific issue by name.
> >
> >         Clusters are akin to files on the file system, really.
> What is the strategy you use to clusterize nodes?

That is for the application developer to decide. If I were
    implementing said bug tracking application, I would choose to
    cluster the issue elements themselves together, and I'd put
    the children on their own cluter.

> > I do hope to foster discussion of this project. I'll check in at
> >    the airport. More questions, please.
> >    
> >    There is a mailing list too. Please join to participate or observe.
> >
> >

> I won't subscribe to a new mail list until I see there is a reason for 
> it, and for sure not before there is any code to take a look at.

Tried to put time in on a Linux bug that keeps me from posting the
    distribution (I develop on OS X, so Linux/W2K issues sneek up on
    me.) It is, however, a challenge to work with two laptops
    on an airplane.

    I will have that zip distribution at end of day PST.
    I hope that once you see the code, you will help me to build a
    quorum on the Momento list.

> >Thanks again for asking.

> You are welcome.

I am very interested in Cocoon community adoption. Please don't
    hesitate to ask questions.

Alan / /
    aim/yim: alanengrm - icq: 228631855 - msn:

View raw message