Re: CORBA again

On Tue, 13 Jun 2000, Timothy Ritchey wrote: > Hi David, > Sorry it has taken me so long to get back with you. I was out of town for > the weekend. I noticed your post on the ORBit list, so I thought I would > send off an email. > > Right now I am working on the fallback method I mentioned for getting all of > the DII information from a call from the idl files in a directory. I am > using libIDL to parse the idl files. > > What kind of progress have you made? Well thing go on pretty well, but I'd rather do without the bug-hunting inside of ORBit... :-) Some simple objects work, the PHP code may look like this: $obj = new Orbit($ior, "account.idl"); $obj->deposit(200); $obj->withdraw(100); echo "Balance is ".$obj->balance()."\n"; Where the IDL looks like: interface Account { void deposit (in unsigned long amount); void withdraw (in unsigned long amount); long balance (); }; Sending an IDL file name to the constructor was just the quickest way to get things working... :-) > This is a pretty deep issue to get right, and I am just now getting to the > point of understanding what they all are. For example, supporting the > in/inout/out parameters, supporting the return of objects themselves and > supporting exceptions all involve some pretty serious interfaces with the > PHP object system, which I do not really have a good handle on just yet. I expect that exceptions must be handled with a "CORBA Environment" just like ORBit does for C. Returning and passing objects should not be a great problem as long as a definition can be found. I have looked a lot at the COM extension, which shows how this can be done. I have not looked at structs, enums or unions yet but they might get their own objects too when they become supported... Something I have not yet found out is how to get and set attributes using DII. Anyone who knows? > Right now I am working on the idl repo code. Basically, on first loading, > the code reads all the *.idl files in a directory, and creates a hash for > each interface it encounters, pointing to the idl file its definition > resides in. When an object is used for the first time, the repo code then > does another parse of the file and loads in all of the operation and > parameter definitions into a structure. > > I am using this approach since people may have large idl files with many > definitions, and they may only want to use a handful of the objects. In > which case, I only want to store the objects they are really using to save > memory and load time. I am not even sure if this is necessary, since I don't > know how people will use the idl file repository. I haven't treated IDL handling this seriously yet, I just load the IDL with libIDL and save pointers to the whole tree and the interface subtree... I guess I will look closer at this (and your source code :-) later on during the implementation. Regards, -\- David Eriksson -/- "An expert in a particular computer language is really an expert in the work-arounds necessary to use this language to perform useful work." - Richard B. Johnson