[gdome] Fwd: Re: Gdome exceptions and CORBA mappings

[Daniel Veillard <Daniel Veillard w3 org>]

  for archiving

Daniel

----- 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
>       hours...
> 
> >    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 ?
> 
> Daniel
> 
> -- 
> 	    [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.