[1175] in Coldmud discussion meeting

root meeting help first previous next last

[COLD] ILU

daemon@ATHENA.MIT.EDU (Sat Dec 7 20:09:00 1996 )

Date: Sun, 8 Dec 1996 01:57:33 +0100 (MET)
From: Miroslav Silovic <silovic@public.srce.hr>
To: coldstuff@cold.org


I did some preliminary work that could affect, say, Genesis-1.2. In
other words, this is a longish-term project. I've been looking into
linking Cold with ILU. ILU is a (mostly) CORBA-compliant Object
Request Broker from PARC.

At this point, it would be a good idea to check
ftp://ftp.parc.xerox.com/pub/ilu/ilu.html
because I'm about to get a bit technical. :)

So, ILU allows you to specify interface to objects in all the
supported languages, and link them across address spaces and
network. In other words, if we add ILU support to Cold, you could just
declare the methods your object exports, along with type declarations,
and WHAM! you have an instant glue to your C, C++, Python, Common
LISP, Java or even FORTRAN code. Ever wanted to do combat system or
monsters AI in compiled Common LISP? Well, here's your chance. The
problem is, of course, writing the damn thing. I have proposed
mapping:

<read the ILU webpage and documentation for more background on this>

	Discrete types map into the most similar Cold type, possibly
	with loss of precision (we might have a true support for
	new types built into the server at the time this gets to the
	coding phase, and better support for new types is something
	I did intend for 1.2, so loss of presicion may become a
	nonissue).

	Arrays map into <$array, [list]>

	Sequences map into lists.

	Strings map into strings, of course.

	Records would map into dictionaries of the form #[[fieldname,
	value] ...]. Of course, the mapping for name can stay fluid
	till we decide on the rest.

	Object : Here's a bit of a problem. ILU's object model is
	classed, with single inheritance (subset of ours, so it's not
	a problem, really. CORBA, I think, only supports SI, too, and
	so does Java). This means that we really want to use frobs.
	The problem, as I see it, is that ILU likes to be notified
	when a client releases the instance of the object. But there
	is no good way to know when a frob has been destroyed (as
	opposed to just being swept on the disk). Frobs would have
	their class automatically constructed from the interface
	specification, and would just keep an object ID (class would
	use some native to forward the method call to the 'real'
	object hiding somewhere in the driver).
	Another way to do this is to implement a good way to add
	new types to Cold, then just use a new type. We could
	set the type to 'unsaveable', then just modify the free
	routine to notify ILU when all the refs are gone.
	Objects are the first thing I need advice on.

	Methods: Corba allows methods to modify their parameters.
	Otherwise they're similar to Cold methods. So, my proposal
	would be to behave as normal if method has no OUT parameters,
	and return a list with the new values for all OUT parameters
	if it does. Any better idea?

	Also, a method call from ILU client to Cold would have to
	spawn a new task. We still have to check how efficient that
	is. My guess is - just barely efficient enough. If I were to
	code a VR in some AI language, I'd code most of it in that
	language and use Cold only as an extension lang.
	

	Exceptions: Well, not much to say here. ILU wants you to
	declare the exception error code and return type, but Cold
	could just check for declaration match and if there isn't
	any, signal 'something weird' to ILU. Otherwise, this part
	at least /seems/ pretty straightforward to me.

Finally, ILU is fairly complex, and writing an interface to Cold might
well be, if not complex, then *interesting* project. I could use help
coding this, and some people have shown lots of interest in precisely
the features we'd get using ILU (link with Java, LINK WITH C++!!!,
inter-server communication using remote method calls, etc).
And I could certainly use feedback. Even if it's just 'COOL IDEA!', or
no, leave it alone, it sucks. :)

	Miro