Hi Paul,
My own experience with this protocol is with a Delphi client [snip]
I've notice that an unreleased objet persist after disconnection,
[snip] AFAIK all the objects should be just droped down on
disconnection, but they're not.
interesting, do you have any measurements of how much
Hi,
As a Delphi developper I do not have Office in debug mode, I have to
find some time to setup all this :)
Paul
Le 11/01/2012 15:30, Tomas Hlavaty a écrit :
Hi Paul,
My own experience with this protocol is with a Delphi client [snip]
I've notice that an unreleased objet persist after
Hi Stephan
Stephan Bergmann sberg...@redhat.com writes:
No, the sending side increments its ref count multiple times for a
given tuple it sends, unless it earlier received that tuple from the
other side (i.e., it is bridged in at this side), in which case it
does not increment the ref count
On 01/11/2012 12:51 PM, Tomas Hlavaty wrote:
Is there a mechanism that when a link between the server and client
bridge breaks, the server releases the resources properly, or do we
get/expect memory leaks?
In some sense this is a QoI issue.
What is a QoI issue? Quality of Information? You
On 01/05/2012 03:52 PM, Tomas Hlavaty wrote:
I'm implementing
http://wiki.services.openoffice.org/wiki/Uno/Remote/Specifications/Uno_Remote_Protocol#Object_Life_Cycle
and can't make much sense of it. It seems to me that the spec is
contradictory:
... unless it considers as bridged in any
On 01/05/2012 03:52 PM, Tomas Hlavaty wrote:
UNO is a distributed protocol. The links should be considered
unreliable.
Do note that UNO was not designed with unreliability of remote
communication in mind. It comes from a time and culture where RPC was
considered cool. The world knows
Hi all,
I'm implementing
http://wiki.services.openoffice.org/wiki/Uno/Remote/Specifications/Uno_Remote_Protocol#Object_Life_Cycle
and can't make much sense of it. It seems to me that the spec is
contradictory:
... unless it considers as bridged in any tuple o, t', where t' is
a subtype of
