Re: image/data loader CORBA instance?


On Sat, 4 Jul 1998, Michael Zucchi wrote:

> Hi,
> > Dirk> Wasn´t there a discussion on the list, where someone mentioned
> > Dirk> that the amiga has done it in this way? Can someone point me to
> > Dirk> some documentation about this?
> > 
> > Apparently the Amiga has something called "datatypes" which allow
> > this.  I don't know anything about it.
> > 
> > 
> > One problem you might have with scientific visualization is that there
> > are a number of important data types.  In fact, it might be hard to
> > even predict all the ones that are important.
> > 
> > This is a problem for implementing the actual API: do you go with a
> > least common denominator (and make the tool less useful), or do you go
> > with something fully general (and big and hard to write)?
> The datatypes interface got around this by having a very simple API
> (both in terms of implementation and use) based on passing around
> 'messages' consisting primarily of a message type (i.e. a method), and
> values required to perform that method.  A thing called a 'tag list'
> was used to pass around these values - basically a type/value pair
> list which could be extended and manipulated as it is being passed
> through the object heirarchy, searched and so forth.  According to the
> manual the object model was based on smalltalk, but I can't comment on
> this as i've not experienced it.
> The api is something like:
>    object = DTNewObject("picture.class", private_class, DTA_FILENAME,
> 		"blah.gif", TAG_END);
>    width = DTGetAttribute(object, DTA_WIDTH);
> etc.  The GetAttribute call is just a convenience function which
> really calls something like:
>     Msg msg;
>     msg.methodid=DTM_GET;
>     msg.attrid=attribute;
>     return DTMethod(object, class, msg);

I have sneeked a little bit through the gimp code and found something
similiar to this: (example copied from gimpdrawable.c)

  return_vals = gimp_run_procedure ("gimp_drawable_update",
                PARAM_DRAWABLE, drawable_ID,
                PARAM_INT32, x,
                PARAM_INT32, y,
                PARAM_INT32, width,
                PARAM_INT32, height,

Khoros does something similiar with get_attrbutes and set_attributes
functions and if I can remember right the tiff format is although build
up with such TAGs. 

I'm not sure if this is the way to go. You only benefit from this if you
although define a set of TAGs which must be implemented by all
applications. The object oriented design and the inheritance hierarchy is
then defined by the TAGs. But couldn't this be done although by a good
class definition.  For sure you can send an arbitrary TAG to an object and
see if it can respond to it, define Forwardes, Protocols and so on. It is
perhaps more like Objective-C. 

For CORBA this would mean, that you define one IDL for all objects with a
few functions that deal with message passing between the objects. The rest
is all done within one mesage handler in the object. Therefore you don't
need CORBA. 

I know there are thousands of ways to do things. Every aproach has its
advantages and its disadvantages. I do not have enough knowledge to build
up a pros and cons list. So my question to the gnome list: Which aproach
will we use. I thought it is CORBA.

So perhaps we can have both: A CORBA defined complex interface and a
message handler routine, that you can call:

object = picture_newWithName ("gnome.gif");


object =  object_new (picture_class, 
                      WITH_NAME, "gnome.gif",


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]