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

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 19:54:01 UTC