Date[  July 15, 1998            ]       Recordnr[        ]
Who[ 
Agenda[
1) Additional information in repository:
   - is my proposal okay?
   - which documentation and implementation tasks result from that?

2) Minutes from one-day workshop: any not-yet reported add-ons/changes?

3) Simple CHAIMS-types in the protocols: how do we represent them there?
   Variant 1: Using native protocol types for simple CHAIMS-types
instead of ASN.1-blobs. Disadvantage: the protocols get more complex,
and the wrappers will have to be enhanced significantly in order to
handle to totally different kinds of data; we would have two quite
different concepts of user-data in the wrappers.
   Variant 2: Using only ASN.1-blobs for user-data. Those that contain
simple types are marked in the repository as BLOB_INTEGER, BLOB_DATE
etc. Whenever the client needs to make comparisons etc. on them, either
the blobs are converted to simple C++ types, or we write a small library
to make comparisons on blobs (in both cases enhancing the already
existing library to convert simple C++ types into blobs).
   What other solutions do you see? What implications of above solutions
do you see? Could everybody prepare a list of the advantages and
disadvantages he sees with each variant?

4) Associative lists in results: we have to enhance the CHAIMS-language
in order to handle associative lists in results. Any proposals how this
could look like? I'm looking for a solution that does not introduce too
many additional language elements, but is elegant and works for all
primitives that can return associative lists (ESTIMATE, EXTRACT,
INVOKEEXTRACT, GETATTRIBUTES) in the same way.

5) Updating the list of tasks in file CHAIMS/planning/tasks, deciding
which tasks come next, and dividing them up among us.


Discussion points for future meetings:
- triples instead of tuples for all data (also basic CHAIMS-type),
descriptive names for hard-coded values in megaprogram
- local megamodules: how to implement? which protocol? wrapper-template
for them?
- scenarios, further megamodules
- configuration management
- general IO-megamodule as local megamodule
- masterclient
 
Further input:
The document to read is ~beringer/Public/language_protocol_2_0.rtf, it
is there as an rtf- and ps-file.

The essentials of what I propose for 2.0:

Variables in a CHAIMS megaprogram:
----------------------------------
We distinguish in CHAIMS between:
- handles: megamodule_handle, invocation_handle
- invoke_status
- data: integer, string, boolean, date, real, opaque
We do not talk of blobs any more in the CHAIMS language and megaprogram,
we just have opaque data. The notion of ASN.1-encoded datablobs is
really an implementation issue. It appears not more in the megaprogram,
but is appears in the CSRT, the CHAIMS protocols and the wrappers.

GETATTRIBUTES, SETATTRIBUTES, GETPARAM:
---------------------------------------
For some reason, we always say SETATTRIBUTES sets the parameters... Why
not just calling it SETPARAM? That name would also be less akward. And
we never ever really talk about attributes. Therefore I suggest we have
in future SETPARAM and GETPARAM, which are the primitives to set and get
client-specific setting of parameters valid for all subsequent
invocations that do not override that setting.

Returning several values in EXTRACT and GETPARAM:
-------------------------------------------------
In the CHAIMS protocol, we just can use attrvalseq.
In the CHAIMS language I suggest the following syntax:
  (myname1=city_list, myname2=airline) = ih1.EXTRACT()
Semantic of that is: From the invocation ih1 I want to extract the
results city_list and airline. The result city_list should be assigned
to my local variable myname1, the result airline to myname2.

Types in the CRST and CHAIMS protocols in 2.0
---------------------------------------------
We have 5 simple CHAIMS types and the complex opaque type in the
megaprogram, i.e. in the CHAIMS language. Yet I suggest that in the
CRST  and the various protocols we always use ASN.1 for transporting all
types, also the simple ones. 
Advantages:
- reduced complexity, no constant handling of special cases
- elegant solution - all data is ASN.1-blobs (Gentype)
- neither RMI nor CORBA offer a type data, instead of inventing yet 
  another encoding scheme, why not just using Gentype and ASN.1 for it?
- we want type and descriptive name information to go along with all
  data transport - why inventing a special scheme for the simple types
   if we already have a perfectly suited scheme with the Gentype?
- thus all data that can be used as parameter to INVOKES is implemented
  in datablobs, only stuff like handles and invocationstatus is treated
  differently

Consequences:
All data will be transported as blobs, i.e. also ESTIMATE returns its
result, which is an integer (or should it be date?), in a blob. 
==> we can use I/O-megamodule as it is
==> we can use wrappers and protocols nearly as they are (apart from
putting estimate-result into a blob, which is trivial)
==> we have still a clean separation between data and composition
==> we have to change the code generated for comparison in the CSRT
(from "number1 < number2" to "BlobToInt(number1) < BlobToInt(number2)")


Minutes[ 

Decisions:
- Implementation of types: we do it as proposed.
- EBNF of CHAIMS language: some minor errors in proposal, updated 
version will be put on web by db. Real_literal and integer_literal 
should encompass the whole range of possible values.
- Returning list of parameters: we do it (language and protocol) as 
proposed.
- Repository: as proposed.
- Type real: we postpone the implementation of hardcoding reals
- Open points: hardcoding of opaque data, type identifier instead of/and 
string, splitting up definition of megamodules in several definitions to 
avoid dependancies
- Tasks: see updated lists of tasks on web


Minutes of weekly meeting of 
==================================