W3C home > Mailing lists > Public > www-dom@w3.org > July to September 1998

Re: Anybody for a server-DOM spec -> transferring nodes and listener model.

From: Mike Shanafelt <shanafme@icubed.com>
Date: Tue, 18 Aug 1998 20:54:21 -0400
Message-ID: <35DA223C.EB29D3D4@icubed.com>
To: Ray Whitmer <ray@imall.com>
CC: www-dom@w3.org
How can I unsubscribe to this email list?

Ray Whitmer wrote:

> Claude Zervas wrote:
> > I guess either next/previousSibling or NodelList.item() can be efficient
> > but usually not both. The best way to solve this would be to introduce
> > iterators. I am advocating the deprecation of next/previousSibling
> > only if they are replaced with iterators (and only for the "server-DOM").
> As I understand it the grove model is where serious/traditional/batch processing
> of SGML is rooted and resembles the previous/next sibling API.  For that reason,
> you will probably have difficulty convincing many that previous/next doesn't
> belong on the server.  I believe browsers were first to expose an indexable child
> collection, making that more expendable on the server, but I still find it quite
> useful on occasion.I guess I look for (and implement) a power implementation for
> my work where both are efficient.
> In my implementation, each child knows its number in the parent sibling list by
> using a BTree with backwards-accessible bucket-relative index, So little actual
> mutation has to occur to effectively insert chidren and virtually slide all the
> higher indices, so that previous/next for all higher children still works.
> Or in a simpler child-list implementation, you just visit every sibling beyond
> the insertion and update the index number so it can index siblings.  Or you
> maintain both a child list and previous/next pointer.
> Or, in a fully-linked implementation with no indexability, you can construct a
> cache.
> None of these implementations seem particularly bad to me.
> If this is a significant issue for lots of implementors, then we certainly need
> to pick one or the other for those specific environments.
> > Your right, and thats why it would be nice to perhaps split the
> > DOM into two or more "packages". One for small client-side scripting
> > applications and one more in tune with distributed server-side
> > applications where resources such as storage are a little cheaper.
> Even with multiple APIs, I never want to arbitrarily mix implementations in any
> environment.  I would lose all efficiency just for starters.  Inserting and
> removing nodes in the hierarchy implies that many more implementation details are
> set in stone -- dictated by the API.  Otherwise, there are private mechanisms
> involved in being a sibling, a child, a member of a query result, a database
> object, etc.
> > It seems like quite a few people are totally against the idea
> > of mixing implementations. I'm not quite sure why since it seems
> > pretty useful. Especially for highly dynamic documents whose structure
> > is maintained by more than one generator.
> > It would be nice to have a public API that supports this since
> > sharing implementations sort of depends on it.
> It shackles any implementation to be forced to incorporate nodes that cannot
> participate in specific advanced implementational relationships.
> > Perhaps a seperate "heterogenous-mixing-server-DOM" spec could be defined? ;)
> You might try throwing together an example interface of node methods that would
> have to be added (in a seperate interface extending Node) for intermixing
> implementations and see how many other implementors would like it.  I believe it
> would make good implementations significantly less efficient, leaving untouched
> only those that chose to implement exactly and directly as the extended interface
> dictated.
> Another starting point would be to make a case that it is useful, and worth the
> sacrifices.  But I think you would still need the transferNode method for
> implementations like mine that would never want to participate because they would
> lose so much in the process.
> Ray Whitmer
> ray@imall.com
Received on Tuesday, 18 August 1998 20:54:32 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 10:46:04 UTC