[gdome] Fwd: Gdome exceptions and CORBA mappings

[Daniel Veillard <Daniel Veillard w3 org>]

  For archiving

Daniel

----- Forwarded message from Raph Levien <raph gnome org> -----

> Date: Tue, 6 Apr 1999 11:29:54 -0700
> To: imain gtk org, Daniel Veillard w3 org
> Subject: Gdome exceptions and CORBA mappings
> From: Raph Levien <raph gnome org>
> 
> Hi Ian and Daniel,
> 
>    I've looked at the exception stuff, and have the following
> proposal:
> 
>    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).
> 
>    Second, exceptions in the dom have a very simple structure: just an
> unsigned short. I think we can do this:
> 
> 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.
> 
>    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.
> 
> 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.
> 
> 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.
> 
> Happy hacking!
> 
> Raph

----- 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.