Re: The DOM and the victim, the iconoclast and the believer
Didier PH Martin wrote: > Didier reply: > Why then also include exceptions? If this where simply a template then why > having so much detail. So much details that the interface can be compiled > and mapped to a particular language. This is more than a template. This is a > fuly fonctional OMG IDL. If the intent was to provide just a template, then > it is easy to write an abstract interface without having to use OMG IDL no? > And yes, you are right the OMG spec do not mention anything about in process > usage. Only inter-operability between object through sockets and IIOP is > properly defined. Then, why use an interface definition that is not adapted > to in-process processing? Most of DOM processing will happen in process no? > Then why use an interface definition with a specification specialized for > remote invocation? Most languages include exceptions. I would not advocate using any language as a template for others to follow without following the letter of the language as much as possible. The only thing not addressed in the CORBA binding was how to evolve a fragile C++ vtable from one version to the next, where there is not even binary a standard that relates that vtable to CORBA. The IIOP interoperability works fine just as it has been defined if you ignore performance. While OMG defines IDL for use in remote processes, IDL doesn't seem to be biased against definitions for local object systems. Whether a particular object system is robust enough to preserve binary compatibility in a covarying object model is a different question, but each language binding is free to pursue the most natural course for that language. For some fragile bindings, it is probably best to declare incompatibility between levels 1 and 2. Others may provide a solution that can be binary compatible with both versions. > Ray said: > I am working on my own C++ binding for DOM right now that has none of the > traditional C++ > fragility problems, again, by introducing a more-robust object model, which > I call CROS > (C++ Runtime Object Standard)... > > Didier reply: > OK Ray, in fact, you are proposing a new middleware. Its OK. So now the > question is: is your spec resolving the problem of intr-address space usage? > can I develop a component in, let's say, Python and have it used by an other > one developed in C++? If yes, you probably defined a binary signature and > if this is the case, please let us know what is your solution. This may be > interesting to learn and probably to use if you provide tool to make it a > reality. Since then, XPCOM is freely available. Or when the WINE project > will have made some progress, their DCOM implementation may be interesting > (but actually lack an IDL compiler). I agree about talent not being related to wallet size. I dislike the COM approach for fine-grained object models. Therefore I am indeed proposing new middleware, but you should give my effort a few months to release a functional DOM and other examples. I have spent many years researching, designing, and prototyping this type of middleware, and the larger XML-based office suites that it makes possible, built on arbitrary content models with completely configurable fine-grained independently-supplied components to match. But I only decided 12 days ago to start building a suitable object model for these purposes so that I could do this work on the side, after, again, spending years investing in Java, only to be repeatedly disappointed with Sun's unwillingness to open up the model so we can solve some fundamental problems there and leverage other great non-Java work in the process. Hence: http://www.xmission.com/~ray/CROS.html You probably shouldn't be interested in the project at this early stage. Whether it will ever reach any degree of acceptance or credibility is far from known. The only reason for you to look at it at this point would be to provide feedback, or tell me that you think the solution is already available somewhere else. I am still mostly modelling designs rather than coding. The tool will come in a month or so. To answer your question, it does solve the problem of binary compatibility when reusing or inheriting code between separately-compiled shared libraries which may have quite different versions of an interface. I think it will compliment a CORBA ORB for inprocess access quite nicely in this respect. It is based upon a core dispatch lookup, which populates dispatch tables. The dispatch table is never stored in the object, but rather as a second field in the object reference, with efficient techniques for caching dispatch tables so they only need to be built once for a particular shared library and so that most operations that are simple with minimal fixed overhead in C++ remain simple with minimal fixed overhead. Dynamic generic classes are easily obtained. Ray Whitmer ray@x... 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!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format