[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: The DOM and the victim, the iconoclast and the believer

  • From: "Didier PH Martin" <martind@n...>
  • To: "David Brownell" <david-b@p...>,"'XML Dev'" <xml-dev@i...>
  • Date: Sat, 15 Jan 2000 23:12:52 -0500

l2 server
Hi David,

David said:
However, note that there should be no problem with a DOM L1 client
invoking a DOM L2 server, since the on-the-wire protocol for those
existing methods didn't change.  And if an L2 client asks whether
it server has L2 functionality, it can avoid ever seeing the system
exception indicating that an L1 server doesn't know about the new
methods.  (Didier, you implied that functionality is missing -- not!)

Didier reply:
David, you are right on this point. Some ORB just throw an exception when we
access a non exiting member. I am actually checking where in the OMG specs
it is explicitely mentionned. It discovered that it is not all ORB that has
this behavior. Now the question is: Is this behavior (to throw an exception
when a required member is not there) is a specified characteristic or simply
because some ORB manufacturers are more clever than others. If it is
specified then it is a question of conformance and now the problem is that a
certain bunch of ORB provider do not play the game right. Or that simply
this behavior non conformant because it is not expicitely mentionned in the
specs. But, before going any further on this, I'll do my homework and try to
find this in the specs.

David said:
Re the problems of defining a cross-language binary-compatible runtime
that has a natural versioning model as well as an API that maps cleanly
and efficiently to C++, Java, C, and the other languages that folk have
demanded CORBA address ... well, let's just say that memory management
is only one of the nasty problems that causes exquisite agony, and say
that despite all the patents filed for in that area, no solution works
particularly nicely.  Most "ABI" standards (ABI == Application Binary
Interface) only handle a small set of those issues, and haven't caught
on well; to get a multi-ORB ABI going has provably demanded more than
any vendor has yet wanted to support.

Didier reply:
Yes memory menagement is problematic, I agree. But also to have a single
binary signature convention may be against manufacturers interests since I
am no longer the prisoner of a single ORB vendor.

David said:
That said ... I think I would agree that changing already-published
interfaces was pretty much against the spirit of IDL.  It'd have been
much more natural to define a new module (C++ namespace, Java package)
that inherited the old interfaces and added new methods:  no change
of current interfaces/contracts.  IDL has multiple interface inheritance
to allow that style of evolution, among other reasons.

Didier reply:
Yes I agree on this, on several ORB that I made my test, inheritence is
working well, so, as you said, if suffice to have the new interface to
inherit from the old. That way, we know waht is part of the old contract and
what is part of the new one. Or, as an alternative solution, that the client
may request for a non changing interface to probe for the DOM provider
support level.

David said:
I've been a victim in this case (don't use JDK 1.1 if you need to mix
DOM implementations with different versions, JDK 1.2 is needed); and
certainly an iconoclast (see above).  And there's perhaps too much
cynic in me lately ... ;-)

Didier reply:
Gee, I guess that you got the same problem as I got with JDK 1.1. This why I
am not reacting, I have been also a victim :-)), and as you, an iconoclast
(its natural David, you have enough experience to be a bit iconoclast in
front of stupid things), I am also a believer...that _we_ can do something
to correct things.

PS: Thanks David for your comment about the exception raised when you access
a non present member. You gave me a hint of where to check for a probable
source of the problem (a) something missing in the OMG specs, (b) non
conformance of several ORBs.

Cheers
Didier PH Martin
----------------------------------------------
Email: martind@n...
Conferences: Web New York (http://www.mfweb.com)
Book to come soon: XML Pro published by Wrox Press
Products: http://www.netfolder.com


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i...
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ or CD-ROM/ISBN 981-02-3594-1
Please note: New list subscriptions now closed in preparation for transfer to OASIS.



PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.