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

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