CERN Accelerating science

Yes, I am still too academic. I aim for a development philosophy which tries to emancipate and empower the user. A truely unconstrained user is productive and free to concentrate on their work (Peter Checkland's Soft Systems Thinking 1984, Ulrich Beck's Critical Systems Heuristics 1987). And users _want_ to be free. ;)

Whether CORBA allows this is arguable. I understand that its complexity drives the creation and use of simpler paradigms in an effort to reduce the burden on the user. Sometimes a paradigm fits naturally to a set of requirements/constraints (a domain) and THIS IS GOOD(tm). But as a domain increases in size, or many merge, this needs a paradigm of such complexity that exceeds it the domain's complexity and the paradigm itself breaks down. At this point expression itself becomes the natural paradigm, as it becomes simpler to describe the domain in language. This shows up in many domains as "domain" or "configuration" languages (eg. VB for Access) - its easier to ask users to describe what they want by means of language as a way of expression within the capabilities of the application(*). Thus the more descriptive the language the better chance there is of describing large or complex domains without constraining the users.

So the question is this. Will the domain(s) be too complex to be adequately described using the get'n'set paradigm? I suggest that it is, as highlighted by investigations into other paradigms (pub/sub, sockets) leading a not to a proliferation of CORBA but a proliferation of differing middleware. CORBA IDL was invented to explicitly describe interfaces in domains in a computer friendly language and assists implementation - the realisation of the original description. But it is not simple, instead it is generic and forces the implementor to explicitly confront all the horrors of distributed computing. But hiding these also hides the best choices for a solution specific to each users needs (like blocking, threading, synchronization). We work at Complexity'R'Us and in some cases there is no way round it. (*) As an aside, this is why XML is so bad, its not actually a language although it appears to be. However it has no common terms (or understanding) defined for a domain in advance and at best only assumptions. If terms are eventually agreed (such as deciding on a schema), the participents may as well agree on something less verbose and process intensive and select features more natural for their domain. Though XML is ideal for parties who agree they cannot agree but still need to transfer data anyway - slightly better than a comma delimited data file.

> - Using CORBA for Quentin's power converters looks like an overkill. But
> have a closer look on this argumentation: I designed my controllers such
> that I can talk to them through a teletype, hence I should not use CORBA.
> This is the argumentation the wrong way: Using strings is unefficient as
> everybody knows - at the source there are floats and bits. But this is not a
> problem for me. The advantages of having a common communication
> infrastructure goes far beyond the question whether we should convert
> strings to floats on the client or on the server side.
> > - Last point is on the hypothetical Alarms API which you mention. I believe
> there should be one. But I hope the code sequence which you shown is not
> something an avarage user has to write. You will have to wrap it and provide
> a simple and implementation. I am not saying that it does not
> have sense to define it as an IDL. When Corba is there anybody can use it.
> But I would also consider using the device/property model as well - not
> because of it's beauty but because it already solved many problems which you
> may have to solve like handling of disconnections or the problem of alarm
> avalanche. The data typing by the way is far from being as ugly as you
> proposed - your Message object can be typed safely as Data object (runtime
> checked but you would provide a wrapper anyway). And since you making this
> API and you can extend your data object, backward compatibility can be
> easily ensured.

Yes, it does depend on your users abilities. A possible wide interface solution however is to use a native language abstraction directly over the CORBA mechanisms that provide the wide interface. For instance, using an automatically generated facade or adaptor class to do this, keeps the application simply decoupled from CORBA, but still keeps wide interface advantages. Such classes also can be automatically generated with code that automates admin functions too, like finding the naming service and retrieving references transparently. Autogeneration and deployment is possible with (Perl) scripting so that additional functions could be added to these classes without the need to recompile the applications. For these functions to be used applications would require modification, as they would need to be for new narrow interface functions, at the users convenience.