[gdome] Fwd: Re: Gdome exceptions and CORBA mappings
- From: Daniel Veillard <Daniel Veillard w3 org>
- To: gdome rpmfind net
- Subject: [gdome] Fwd: Re: Gdome exceptions and CORBA mappings
- Date: Wed, 7 Apr 1999 19:24:16 -0400
----- Forwarded message from Daniel Veillard <Daniel Veillard w3 org> -----
> Date: Wed, 7 Apr 1999 05:16:02 -0400
> From: Daniel Veillard <Daniel Veillard w3 org>
> To: Raph Levien <raph gnome org>
> Cc: imain gtk org, Daniel Veillard w3 org
> Subject: Re: Gdome exceptions and CORBA mappings
> Hi Raph and Ian,
> > First, we have a design decision: should we add the exception
> > mechanism to all methods, or just the ones that are defined in the idl
> > as being able to raise exceptions? I vote for all, based on the fact
> > that we may want to generate our own exceptions when, say, a pointer
> > is NULL (see also Exception DOMException in section 1.2 of the DOM
> > level 1 rec).
> Agreed genericity is important and is for some reason the next version
> of the spec add exceptions on some methods we won't be ammoyed.
> > Second, exceptions in the dom have a very simple structure: just an
> > unsigned short. I think we can do this:
> That's what I did too in gnome-dom :-), it maps perfectly to the CORba
> suggested C mapping.
> > For idl methods returning void, the corresponding gdome function
> > returns the exception code, or 0 if there is no exception.
> > For idl methods not returning void, we add an additional "unsigned
> > short *exc" argument. It is the responsibility of the _caller_ to set
> > this to 0 before invoking the method. In exception cases, the function
> > sets *exc to the exception code.
> > This permits, I believe, very simple coding of exceptions. For
> > example, to allow exceptions to propagate up the calling hierarchy,
> > one need merely pass in your exc argument to child functions, and do
> > "if (*exc) return;" after invoking the child function. I have defined
> > zeroing exc as a caller responsibility so that functions that don't
> > raise exceptions need not have any additional code for the exception
> > mechanism.
> A few things:
> - why separate the mechanism whether it's return void or something
> else having a generic mechanims independant of the initial function
> signature is IMHO a good thing
> - my opinion on the *exc initialisation is that it would be better
> done at some stub level. For CORba calls in the servant handler
> and for local call, why not define the calls as macro doing the
> initialization. if something can be automated, it has to be
> automated ! Putting more burden on application writers is usually
> a bad thing, they may forget and track the uninitialized bugs for
> > It seems to me that ifgen.pl can be extended to autogenerate all of
> > the code needed to connect Gdome to CORBA. Interfaces in both
> > directions should be generated, i.e. a CORBA interface for the Gdome
> > functions, as well as an implementation of the Gdome interface using a
> > remote DOM.
> > This autogenerated code has a number of responsibilities:
> > 1. Mapping CORBA names to Gdome names. For example, a typical Gdome
> > function is gdome_el_setAttribute. The corresponding CORBA name is
> > POA_Element_setAttribute.
> > 2. Interconversion of UTF16 (CORBA DOM) and UTF8 (Gdome) strings. I
> > could probably be prevailed upon to write fast code for this,
> > especially optimized for the common ASCII case.
> Yep, we do all agree that UTF8 is the way to go for our internal
> representation, right ?
> > 3. Mapping of Gdome exceptions to CORBA. See CORBA section 19.22 (page
> > 19-26) for the details on how to do this. In outline, if the
> > returned exception value is nonzero, you do a CORBA_exception_set
> > on the CORBA_Environment passed into the skeleton function.
> including the exception value initialization :-)
> > 4. Mapping of the storage management. Happily, the Gdome storage
> > management framework (unref functions for each major type) should
> > interwork fairly nicely with CORBA storage management.
> > Careful reading of chapter 19 of the CORBA 2.2 spec (easily
> > findable from http://www.omg.org) is essential before cooking up any
> > of this code. I might suggest handcoding a couple of interfaces and
> > methods before trying to get everything in the autogen framework.
> Also have a look at the stubs generator i wrote for gnome-dom, its
> completely macro based, so not easilly readable but may give some ideas.
> On a completely different point of view, I hate "floating mail" i.e.
> non-archived discussions, I would be happy to create a gdome mailing-list
> and have an archive on rpmfind.net ... What do you think ?
> [Yes, I have moved back to France !]
> Daniel Veillard w3 org | W3C, INRIA Rhone-Alpes | Today's Bookmarks :
> Tel : +33 476 615 257 | 655, avenue de l'Europe | Linux, WWW, rpmfind,
> Fax : +33 476 615 207 | 38330 Montbonnot FRANCE | rpm2html, XML,
> http://www.w3.org/People/W3Cpeople.html#Veillard | badminton, and Kaffe.
----- End forwarded message -----
[Yes, I have moved back to France !]
Daniel Veillard w3 org | W3C, INRIA Rhone-Alpes | Today's Bookmarks :
Tel : +33 476 615 257 | 655, avenue de l'Europe | Linux, WWW, rpmfind,
Fax : +33 476 615 207 | 38330 Montbonnot FRANCE | rpm2html, XML,
http://www.w3.org/People/W3Cpeople.html#Veillard | badminton, and Kaffe.
] [Thread Prev