Re: [Fresco-devel] A Graphic Dictionary

Tobias Hunger wrote:

 >>>Downside: As this Dictionary is not exported via CORBA this dictionary is
 >>>not accessible for remote Graphics and cannot get queried by
 >>>applications. It is purely server internal.
 >>
 >>I don't think that this is a drawback at all. We are talking about a
 >>debugging tool, right ?
 >
 >
 > It does not allow to get any information on client side graphics. Since that
 > is used to prototype and prototypes tend to be buggy I do consider this to be
 > a bit of a problem.

Then provide a debug-enabled runtime environment for your client !
Debugging distributed applications is hard enough, no need to make it even harder.

 > Being server internal further mandates that the scenegraph debugger is build
 > into the server. Nicholas' approach of a client doing that won't work (or at
 > least won't get to the information stored in the dictionary.

Why not ? We could well add a method to the Server that provides safe
access to the dictionary (with the help of a client-side runtime environment,
of course. Now before you ask: I'm *not* against exposing debugging stuff through
CORBA, but I'd much prefer to isolate the relevant stuff, in this case make it
a simple method that doesn't have any effect on the scene graph protocols.
What you originally suggested was a change to the Graphic interface, which is
much too intrusive for my taste.


 >>>What do you think about such a Dictionary? Is that a good thing to have?
 >>
 >>As I said, I'd suggest you start outlining what exactly you want this to
 >>help you with, i.e. some use cases would help to see where such graphic
 >>names would help.
 >
 >
 > What the dictionary can be used for now if this:
 >     a) give a name/description to a graphic
 >     b) figure out where it came from
 >
 > a) is mandatory to be able to make any sense out of a dump of the scenegraph
 > in whatever form. b) is just nice to have IMHO, some kind of backtrace for
 > Graphics.

hmm, isn't b) implicit when you include a typename into a) ?
After all, it's much more the graphic type you want to know than where it came
from. If the object is buggy, you need to know where the code is.

 > I might want to add
 >     c) get access to the implementation
 > later. That could be nice, but we'd need some more elaborate tool then a
 > simple 'scenegraph dumper' I'm aiming for right now to make use of that.

I don't agree. c) is the first thing I'd start with. a) and b) are secondary.

Regards,
		Stefan