Re: ORBit2, IDL compiler improvements



At 17:57 24-08-2000 -0400, you wrote:
>On Thu, 24 Aug 2000, Darrin Thompson wrote:
>
> > I don't see SSL on your list. After Sept. 20 that could be a NICE compile
> > time option.
>
>I didn't mention it because I don't consider it as requiring too much
>consideration (it should be just another transport to plug into libIIOP).
>But, we need someone to volunteer to keep it in mind and code it etc. - I
>don't know much about using openssl.

I have been debugging some own code that integrates with a library that 
does openssl communications.
All that is done is reading in some key files, and some extra calls on top 
of a socket (at least for outgoing).

I have never written any ssl code before, but I can probably hack together 
a client in 1 hour by now.

The reason I am using ORBit now is, that I have some java code in Lotus 
Notes that needs to interface to library written in C that does the SSL 
stuff + more. First I let notes call the native methods. Result was, that 
the whole notes server went down a few times. So I wrote a Java RMI server 
to get process isolation. This almost worked. But one function in the 
library would crash the server   at unpredictable times, so I spread 
debugging messages all over. Never found the error.

So now I have decided to use CORBA and something else but java on the 
server side, and after looking at ACE+TAO (a huge package), I picked ORBit 
instead. Now I just need it to be multithreaded.


> > The coolest feature in the world IMO would be the ability to hack out
> > a multithreaded CORBA servant in Perl (that experimental stuff) or
> > Python or TCL with ORBit as the ORB. (someday...)
>
>I don't know - I want to avoid doing things unless there is a real need
>for them, 'cool' or not.

Multithreaded is good. Right now I can do without. But I will need it for 
scalability soon. Problem is, that my server object takes 5 - 120 seconds 
to complete. And if the web users hist OK too many times, the queue will 
become too long (denial of service).

>But, as far as I can understand, all you are wanting is for complete Perl,
>Python, and Tcl bindings, which is perfectly reasonable.

For me this is lower on the list than multithreading.






[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]