minutes of ESC call ...

[Michael Stahl]

On 02/03/12 10:32, Michael Meeks wrote:
> 
> On Fri, 2012-03-02 at 09:29 +0100, Stephan Bergmann wrote:
>> Micheal, I think I still don't understand what you are up to here.  What 
>> does logging have to do with XUnoTunnel ?
> 
> 	Correct me if I'm wrong, but as soon as we start doing bridging - which
> is necessary for logging - then instead of passing C++ object handles
> around which will dynamic_cast<> properly, we end up with some bridge
> object in the middle instead, and all instances of dynamic_cast break -
> is that right ? :-)
> 
>>   (And we want as little as possible of the XUnoTunnel hack, anyway,
>> so no idea what your "dynamic_cast<> alike" idea is?)

the problem is that sometimes XUnoTunnel is necessary, e.g. you in our
applications where UNO is not used internally, but has been tacked on as
wrappers, you cannot implement a method that takes a parameter which is
from the same application and do anything useful with it without
XUnoTunnel (or dynamic_cast), because the UNO API (of course) does not
give access to (necessary) implementation details.

> 	Well - so - my wonder was whether we could create something much
> lighter, that does XTunnel's job - built into the UNO core code itself,
> and bypassing such bridges (with some suitable simple, pleasant and
> readable syntax as dynamic_cast<>).

so you want an uno Reference that points at a (potentially) remote
object, but still want to get a C++ pointer to that?  i don't believe
there's a simpler solution than XUnoTunnel for this without giving up
safety.

>> Make it into a "random UNO improvements" project?  Hm, not sure.
> 
> 	;-) well - as you like. IMHO it makes sense writing these things up in
> some detail for people new to the project.

hehe, to me it looks mmeeks just wants to get you to mentor anything at
all  ;)