Re: image/data loader CORBA instance?

[Michael Zucchi <zucchi zedzone box net au>]

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);

Tuxedo (TP/Monitor, sort of CORBA-like low level messaging system) uses
a similar but more complex thing called a 'fielded buffer' which lets
you do similar things - i.e. an amorphous data structure which can be
extended (transparently) and queried and modified by both the client
and server.  Tuxedo also uses the fielded buffers 'field type'
(independent of the field identifier - the high bits at least) to
perform marshalling and un-marshalling across network calls.  Tag
lists just have a tag id, which doesn't include the type (the object
class knows what it is by the tag id).

Anyway, the point is that these are both (relatively) simple, and very
very general.  e.g. the tuxedo interface to all services is simply

success = tpcall("servicename", input_data, input_data_len,
	&output_data, &output_data_len, FLAGS);

If the input_data or output_data happens to be a fielded buffer, then
the call (and result) can contain whatever arguments are required.

The datatypes interface is simpler (since there is no need to build
the taglist like you do with fielded buffers):

 result = DTDoMethod(object, DTM_METHODID, DTA_DTARG1, arg1, DTA_DTARG2,
	arg2, TAG_END);

The object's class handler just gets these values as a methodid and a
taglist.  Switches on the methodid, and scans the taglist as it sees
fit (depending on the method of course).  If it doesn't understand the
method (i.e. the "default:" case), it just passes it to its superclass
(i.e. method inheritence).  If it does understand the method it can
process it and return (i.e. method overloading), or some combination
of the two.  Very simple to code, very compact too.  Not really any
slower than a "function pointer" object method, unless the class
heirachy is very deep - but object and class creation and maintenance
is much simpler.  The class only needs one function pointer, the
'dispatch' routine, where all of the "smarts" are handled.

Regards

 Michael

PS sorry to those who've seen this rant before :)  I'm attempting to
demonstrate that complexity isn't always necessary ... infact, a
properly defined set of primitives is often the really important thing
(which underlies much of the Amiga OS in general, particularly the IPC
mechanisms, shared libaries, device interface, BOOPSI and datatypes,
i.e. the really core stuff.  The same can be said for much of Tuxedo's
design too).

-- 
     ///   `... thinking is an exercise to which all too few brains
    ///     are accustomed.' - First Lensman, E.E. `Doc' Smith
\\\///  
 \\\/   Michael Zucchi, B.E.                 zucchi@zedzone.box.net.au