From beringer@DB.Stanford.EDU Wed Mar 11 14:15:54 1998 Received: from Sealion.Stanford.EDU (Sealion.Stanford.EDU [171.64.75.55]) by DB.Stanford.EDU (8.8.8/8.8.8) with SMTP id OAA29139 for ; Wed, 11 Mar 1998 14:15:44 -0800 Sender: beringer@DB.Stanford.EDU Message-ID: <35070E19.5AAE@db.stanford.edu> Date: Wed, 11 Mar 1998 14:20:09 -0800 From: Dorothea Beringer X-Mailer: Mozilla 3.01Gold (X11; I; HP-UX A.09.05 9000/712) MIME-Version: 1.0 To: chaims@DB.Stanford.EDU Subject: Minutes weekly CHAIMS meeting Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mozilla-Status: 0001 Content-Length: 2133 Minutes weekly CHAIMS meeting 3/11/98 ===================================== I/O-megamodule - ASN.1 ---------------------- Hao presented how ASN.1 will be integrated into the I/O-megamodule (Java-module, ASN.1-conversion-module, JNI-interface between them). Hao suggested the following method-interface of the I/O-megamodule: h1 = IO.INVOKE ("output", Data = mydata, Type_Name = mytype_name) h2 = IO.INVOKE ("input", Type_Name = mytype_name) mydata2 = h2.EXTRACT () Criticism: The megaprogrammer also has to provide the type-name for the data he wants to output (which of course he could get from a megamodule), something he really should not have to care about. Also, this results in having always a pair of related parameters when invoking the output-method. Other variants: - having only simple dump-function for output (but that does not resolve the problem of input) - having a format-description instead of a type-name (similar problems as with the variant of Hao?) - inserting the information into the ASN.1-datablob and having general classes in the I/O-megamodule and the wrappers to treat that Actions: Pankaj and Hao will test how general class would work until next Friday. Special ASN.1-meeting on Friday 20th pm, unless we have to postpone it due to conflicts with finals. Second part of talk Ron about CORBA ------------------------------------- Ron mentioned 4 points why CORBA could run into troubles: 1) Are distributed objects really the right paradigm for distributed applications? 2) CORBA has no common code base (only requirements documents, waterfall process) 3) CORBA is leeding edge (no more bleeding edge), not yet trusted middle. Yet for something as crucial as a middleware system, people are rather looking for trusted middles. Due to waterfall approach and not reusing other trusted middle technologies (as e.g. DCOM does with DCE), this could still go a long way. 4) There is a fundamental flas with certain itilities like reliability, availability and scalability, partly due that it was just not yet adressed, partly due to the paradigm of distributed objects. That's all, Dorothea