Re: [Evolution-hackers] gtkhtml - composer not starting ...

[Michael Meeks <michael ximian com>]

Hello Mark,

On Thu, 2002-05-23 at 02:17, Mark McLoughlin wrote:
>         I won't address the problem you're trying to solve, because I
> haven't had much experience of it, but the way you plan to implement
> the solution is just plain wrong.

	It's a real shame that you didn't understand the problem before
considering the efficacy of the solution I proposed.

	Let me re-state it more simply;

	we need the following:

	a) Stubs that during invocation will not re-enter
	b) Stubs that during invocation will re-enter

	We also would like to be able to delay server side request processing
until idle, here the requirements fit closer to an extra POA policy as
you suggest - but for the fact that we do not want the policy to apply
to all methods ( eg. ref / unref / queryInterface ) - but to a sub-set
of methods.

	I imagine it might be possible to do something grotesque that would
lookup methods by name, and provide a custom OA ( with a big API, a
secondary method lookup, or somesuch ) to achieve the latter goal - but
it seems unnecessarily complicated to me.

>         The idea behind IDL is that you specify the details of the
> interface to the service i.e. you seperate the details of the
> implementation from the interface. The way in which requests are
> processed is an implementation issue.

	Well - there is no need for the request processing data to be in the
IDL per-se, I'm more interested that it's in the generated IMethod data
so we can get at it quickly. If you want to be a purist, we can have a
separate file ( perhaps an XML:panacea file ), that marks up the
generated C -common.c source, but it's going to be a pain.

	At the end of the day, we need to associate processing data with each
method, and it makes lots of sense (to me) to do this at compile time,
rather than execution time.

	I will however alter the ORBit2 ABI before releasing, so that we push
the index into the IMethod data into the stub invoke, so we can try and
associate such things on a per client basis - but this is just futile.
We need to be able to control stub invocation re-enterancy, and this is
just not possible (nor desirable) to do on a per CORBA_Object handle
basis [ not to mention that all the CORBA_Object handles are shared
amongst clients necessarily; selecting amongst the different options on
incoming object references is just impossible blah blah. ].

>         Not only that, but its a detail of the POA. And the way the
> POA behaviour is configured is through the use of POA policies. Think
> about it - how different from the RequestProcessingPolicy, the
> LifespanPolicy or the ThreadPolicy is this? So really, if you want to
> make to make this behaviour configurable, you should do so by adding
> another POA policy.

	A POA policy is not really powerful enough to do what we want to do
IMHO, possibly we could make it good enough - perhaps conditional idle
processing for oneway methods. But again this only solves half the
problem.

	In conclusion - no I'm not suggesting binning CORBA, adding some
#pragmas or other method annotation either in or parallel to the IDL to
describe how we want the processing to occur seems not unreasonable, nor
wrong to me. Furthermore, other ORBs will ignore this information,
leaving us CORBA compatible on the wire, CORBA compatible at the IDL and
API level - but without uncontrolled re-entrancy in our implementations.

	I hope this helps explain what I propose,

	Regards,

		Michael.

-- 
 mmeeks@gnu.org  <><, Pseudo Engineer, itinerant idiot