[omniORB] ILU to omniORB (lengthy)

[Stefan Seefeld]

Geoff Gerrietts wrote:

> 1.  ILU had an alarm() function....
>     We have a service that manages user sessions. It keeps them all in
>     a great big dictionary. Every few minutes, during an idle cycle,
>     ILU would invoke a callback function that scanned the dictionary
>     for expired user sessions, similar to the way you'd register a
>     signal handler with alarm().
> 
>     I have seen no API in omniORB that replicates this feature. I
>     presume the suggested approach would be to spawn a worker thread
>     that periodically cleaned out sessions. Am I correct?

yes. There is no builtin solution because there are so many ways to deal
with the problem. I use a worker thread in the server that pings clients
to figure out whether they are still alive. If not, all the resources
allocated on behalf of that client are freed.

This approach requires you to define a 'Session' interface providing
a 'ping' method or similar.

> 2.  ILU's integrated dictionary support was handy....
>     ILU had a feature that allowed you to map a sequence of key/value
>     pairs to python dictionaries. This proved handy on a couple
>     occassions early in the development of our application and it's
>     become ubiquitous. That gives rise to two sub-questions:
> 
>     2a. Am I mapping this right?
>         I reviewed a couple different options, including mapping to an
>         Any, and mapping to a sequence of string/Any pairs. I settled
>         on preserving the original string/string encoding to avoid the
>         overhead of packing/unpacking the Any objects. Was that folly?

That depends on the types the values can assume, I would think. If you
can handle the marshalling of your types from/to strings, it might indeed
be simpler to use string/string pairs. But if you find yourself redesigning
a type system and complex marshalling procedures, it would probably be
wise to use existing technologies such as CORBA::Any.

>     2b. Am I making trouble for myself down the road?
>         I've settled on a solution where I subclass the
>         _objref_Interface and override client-side calls where the
>         dictionaries might be used in the parameters or might be
>         returned, and perform the marshalling there. This seemed
>         superior to trying to do the marshalling/unmarshalling at
>         every place the methods were employed. But am I making trouble
>         for myself? Is the _objref_Interface name likely to change? Is
>         there a "better" way to do it?

I wouldn't ever touch _objref_Interface. It's an type internal to omniORB
and not supposed to be used by application code directly. Relying on it
makes your code non-portable.
If you really want to care for the marshalling yourself, you could use
a wrapper class. Assuming a 'Worker' class is used that expects typed arguments,
you can define a 'Caller' interface and implement it by a 'CallerImpl' which
becomes responsible for the marshalling:

class Worker:
   def process(self, typed_dict):
     ...

class CallerImpl(Caller):
   def __init__(self, worker):
     self.worker = worker
   def process(self, string_dict):
     typed_dict = unmarshall(string_dict)
     retn = worker.process(typed_dict)
     return marshall(retn)

Again, depending on the domain of your values, this may or may not be
a good idea.
At first sight I would tend to think this is premature optimization,
i.e. I would use a typed dictionary (string/any pairs), and only if
it turns out to be a performance bottleneck I would look for alternatives.

> 3.  omniidl's python backend makes some assumptions....
>     The omniidl stubber drops a file Module_idl.py and creates Module
>     and Module_POA packages, all in the current directory. The
>     __init__.py in each package import module_idl, which only works if
>     "the current directory" is the current directory at runtime, or
>     "the current directory" is on PYTHONPATH. Neither of these options
>     is particularly good for my client application.

note that omniidl has a number of options to change the current working
directory while generating the output, as well as how to lay out the
generated python files. Try 'omniidl -h -bpython' for details.


Hope this helps,
		Stefan