Re: Bag IDL

[Mike Kestner <mkestner ameritech net>]

Michael Meeks wrote:

>         AFAIR we encode event names with a path, type and subtype field
> that ensures that multiple interfaces can be aggregated to a single event
> source and have no event name conflicts - the path being the IDL path, the
> type and subtype being interface specific. eg. title:changed.

And my point is that there is no reference in the IDL to how these type
and subtype are defined and used with regard to property related
events.  It's RTFS to find the buried API.
 
> > The old PropertyListener interface provided a well defined API for the
> > types and format of events produced by a bag.
> 
>         I forget how this worked, however, the critque of Any's complexity
> either applied equaly to it - or it required unneccessary round trips I
> forget.

IIRC:

interface PropertyListener : Unknown {
	void changed (in string prop_name, in any value);
}

Compare the readability of this to what we have now.  I must catch a
generic event name and decode it from an unpublicized string value like
"Bonobo/PropertyBag:changed:prop_name".  I've got to parse out the
prop_name.  I agree that the Any complexity is trivial in the property
listener case, since properties map to basic types.  Hopefully the
example below will clarify my concerns about the "any" param of
Listener::event().   

>         Either way, the complexity of Any's is more percieved than real,
> and is no worse than eg. gnumeric's Value structure. and not more
> complicated than neccessary [ except for union ].

Okay, maybe you can slap me with a cluestick regarding what I just
wrestled for the GNOME/Draw/Shapes interface.  I need to emit a
shape_added event which provides both an ObjRef to the new Shape and the
Shape's name.  In order to produce this event using the generic
Listener/EventSource, I considered a couple of options:

1) Encode it as a struct and bury that in an any, which I believe means
I have to create a CORBA_typecode for my new event structure.  The any
that arrives on the client side won't be automatically demarshalled into
a C structure, either, correct?  I think clients need to know a lot
about typecodes and struct demarshalling to use this approach, so I
bailed on it quickly.  

2) Store the name and objref into separate any's, stuff them into an
AnySeq, and stuff that into an Any.  This seemed the more promising
approach from a reusability standpoint.  I spent about 4 hours trying to
make this happen for my add_shape event before I gave up.  

I then spent about 15 minutes to hack a ShapesListener and
[add|remove]Listener methods.

The result is that users of the Shapes interface can now create a
ShapesListener, attach it directly to the Shapes ref instead of querying
for another interface, and provide a callback to the following signal:

	void (* shape_added) (gchar *name, GNOME_Draw_Shape shape);
 
>         I believe the decision to go with a standard event source /
> listener was the correct one.

I think it has a lot of potential, and I feel like I put in a serious
attempt to use it for my project.  Perhaps I'm a moron, but going into
the above effort, I thought I had a decent understanding of how
CORBA_any's worked.  Until BonoboArg's are beefed up by someone smarter
than me, I don't see how I can use the generic Listener for anything but
simple events, and even then, I think the readability of the interface
takes a hit.

Mike