Implementing XPCOM objects in Erlang. (Modificado por Héctor Rivas =?iso-8859-1?q?=20G=E1ndara?=)

[Mikael Karlsson]

Is it possible to make use of Erlangs Corba support?
The ic (idl compiler) could maybe be patched for XPIDL
and orber used for resolving ObjectReference -> PiD ?

Mikael

tisdag 31 maj 2005 17:21 skrev Héctor Rivas Gándara:
> El 31/05/2005, a las 14:50, Ulf Wiger (AL/EAB) escribió:
> > Why do you want to make the gen_server reentrant
> > in the first place?
>
> I'm developing the Erlang XPCOM binding. XPCOM is component tecnology
> similar to COM used in Mozilla internals. A lot of interfaces of
> mozilla receives an object as parameter and execute callbacks on it.
>
> My first option was implement the component instances as processes.
>
> > Another way to implement objects is to provide a module
> > with a set of APIs that operate on an abstract data type.
>
> That's the other option.
>
> If the object is readonly or it will be accesed only by the C++ side
> (the C++ will never do concurrent calls), there is no problem, but
> there are some otherwise:
>
>   - The object will occasionally be passed to the XPCOM side (in C++).
>   - so a reference to it must be created and the object will be stored
> in an ORB to allow the  C++ side reference it.
>   - I can't known when the C++ side (or even a local process) will call
> the object and change the object state.
>
> I mean, I can't control the object access to follow the  single
> assignment rules.
>
> One solution can be create an "object dictionary" with entries like
> ObjectReference-ObjectState.
>
> But this have more problems:
>   - the object support concurrent access (from C++, from Erlang
> processes) and
>   - must allow reentrant calls.
>
> To solve the first I could add some logic to the Object Dictionary to
> allow lock the object state until a running method does not returns
> (simulate synchronized methods).
> But then it is not reentrant, so I should use a monitored lock (the
> actual process can do reentrant calls).
> But now I have other problem: If I use a monitored lock the
> XPCOM-Erlang binding must offer thread consistency (there is a call
> from Erlang to C++ and back to erlang again, the process must be the
> same)
>
> ...
> Too complex all. :-/
>
> Anyway, I probably would allow the two options by setting an option in
> the object creation function. The programmer can choose:
> - use process objects if the object is not readonly and will be accesed
> by C++ and Erlang
> - use record objects if the object is readonly or only accesed by the
> C++ side.
>
> I've implemented my behaviour with callbacks like:
>
> method(MethodName, InParams, From, State) -> {Reply, NewState}
> 	Reply = {ok, OutParams} | noreply | {error, Reason}.
>
> The objects implemented with this callbacks could be easily run with
> records by simply change the behaviour code: I only need a dictionary
> that could translate ObjectRefence -> {data, ObjectData} | {process,
> ObjectPid}.
>
>
> Please, comments / suggestions?
>
> --
> Greets