RE: Need more detail.

[Reinhard Müller]

> If there is "no IDL," then this sounds like it is
> distinctly NOT a
> CORBA-based system, as IDL is the basis for defining
> CORBA applications.

I will try to make things clearer here, at the risk to confuse even more :)

GNUe Architecture:

GNUe Forms, GNUe Reports
   |
GNUe Application Server (GEAS)
   |
Database backend

The Application Server will provide business objects to Forms/Reports.

We have defined the term "business object" as being as being a set of
Data that belongs together (basically think of a row in a database table)
plus "methods" (code that is called from outside the object, like due to
user interaction or from another object) plus "triggers" (code that is
automatically called from inside the object when certail events occur,
e.g. to validate the data).

Business objects will NOT be CORBA objects. This means that NEITHER
has every business object it's own static IDL, NOR will there be dynamic
interfaces. There is ONE COMMON STATIC INTERFACE via which Forms,
Reports and whoever else wants can communicate with the business objects.
This static IDL defines methods like "get_field_list()", 
"get_field_property(field)"
or "get_field_value(field)", "get_method_list()" and "call_method(method_name,
param_array)". (of course these are named differently in the real IDL, it's just
to explain)
So to say, we have no _pure_ CORBA based system.
There are plans to add support for dynamic interfaces, but that has got very
near the bottom of the TODO list during the last weeks, as we don't see the
_real_ advantage we gain from dynamic interfaces.

But how are we going to implement business objects?

As said above, business objects consist of properties (the data fields),
methods, and triggers.
Business objects are defined by simply writing an ASCII file that tells
the Application Server:
* what properties does the object have (with which datatype)
* how to store these properties in the underlying database, and how to
  calculate or otherwise retrieve non-stored properties
* how the object is related to other objects (master-detail, lookup etc.)
* which methods for this object are available
* which triggers for this object should be called at which event
Andrew Hill and Andrew Murie have (in our opinion) done a great job
by defining a _very_ simple language for defining the above; that
language looks a bit like the IDL language, but it's definitely NOT an IDL.
The actual method and trigger code are written in seperate files; as a
first step we will support python there, but we are planning to have also
the possibility to write methods and triggers in scheme, C or maybe even
more.

So, when defining a business object, you provide
a) An ASCII file which defines, in our self-defined language, the business
   object (this file is the mystical ".cld" file)
b) One ASCII file for each method and each trigger of the object. These
   files contain the python code for methods/triggers. In this code, you can
   access other object's properties and methods. The filenames for these
   files are given in the .cld file.

Once these files are written, the Application server can access them, and
dynamically provide the new (or changed) objects to Forms, Reports, and
other objects, by the means of its set-in-stone, never-changing static
interface.
Note: no need to compile an idl or anything for activating changes; no need
to be familiar with CORBA for writing a business object, just write an ASCII
file in vi (or emacs of course), save it to a proper directory, and voila!

Ok. End of technical stuff here. Now some personal remarks.

We (the core team which is mainly talking over IRC) must excuse for our
lack of documentation. This is BAD BAD BAD. It's just that it's hard to write
docs when you are actually struggling to get along with your code.

We (the core team) must excuse for our lack of communication to the
outside. This is BAD BAD BAD.

We (the core team) would be very happy about ANY comment to the above
(at least this is true for me :) - as long as we can keep it technical.
(Sorry that we (or at least I) are (am) no longer interested in philosophical
flame wars).

We would be even happier if somebody pointed out some serious
design flaws that are in our architecture. If you are assume some, you
may even ask additional questions :)

Of course we would be happiest if you told us this design is great.

I hope that what I wrote is understandable, and - even more important -
answers your questions.

And, Christopher, sorry for my painful English ;-)

Thanks,
Reinhard