Re: Serious Bonobo Problem for Sun

[Colm Smyth <Colm Smyth Sun COM>]

>Delivered-To: gnome-components-list gnome org
>From: Dietmar Maurer <dietmar ximian com>
>X-Accept-Language: en
>MIME-Version: 1.0
>To: Colm Smyth <Colm Smyth Sun COM>
>Cc: darin eazel com, sandmann daimi au dk, michael ximian com, mjs eazel com, 
miguel ximian com, brian cameron ireland sun com, 
gnome-components-list gnome org, Brian Cameron Sun COM
>Subject: Re: Serious Bonobo Problem for Sun
>Content-Transfer-Encoding: 7bit
>X-BeenThere: gnome-components-list gnome org
>X-Loop: gnome-components-list gnome org
>X-Mailman-Version: 2.0beta5
>List-Id: component/document model <gnome-components-list.gnome.org>
>
>Colm Smyth wrote:
>
>> >From: Dietmar Maurer <dietmar ximian com>
>> >X-Accept-Language: en
>> >MIME-Version: 1.0
>> >To: Colm Smyth <Colm Smyth Sun COM>
>> >CC: darin eazel com, sandmann daimi au dk, michael ximian com, 
mjs eazel com,
>> miguel ximian com, brian cameron ireland sun com,
>> gnome-components-list gnome org, Brian Cameron Sun COM
>> >Subject: Re: Serious Bonobo Problem for Sun
>> >Content-Transfer-Encoding: 7bit
>> >
>> >Colm Smyth wrote:
>> >
>> >> 1. middleware notifies server of client death; this is the best solution
>> >>    as it is transparent and operates at the a common low level; since the
>> >>    middleware is CORBA which (I believe) has no standard that supports
>> >>    client death notification, this can't be used.
>> >
>> >Yes, this is not supported.
>> >
>> >> 2. server pings clients; since a client normally invokes a server, this
>> >>    is a slightly unusual situation but bi-directional communication is
>> >>    supported by recent GIOP standard; technically possible, but it
>> >>    complicates the architecture by requiring clients to export a
>> >>    CORBA interface so not to be recommended; if this mechanism were
>> >>    chosen, it would be best if the Client::ping() interface were
>> >>    asynchronous.
>> >
>> >The server does not know it's clients, and a client can pass server object
>> >references to other clients. I think this will never work.
>>
>> If this solution was adopted, we would add a register_client() method
>> to the Bonobo Unknown interface - pretty simple.
>
>And if you pass an server object to another client you have to unregister
>the old client, and register the new one? IMHO not "pretty simple".

If 'another client' is an object within the same client process, it doesn't
matter. If 'another client' is another process, it needs to establish
a relationship with the server independently.

Maybe I can make this a little plainer; there are two variants of the
client leasing mechanism:

1. one that supports Bonobo ref-counts; this requires per-client tracking
   by the server, which requires that each client invokes a register_client()
   method on each object server that it uses.
   
2. one that doesn't require or support Bonobo ref-counts; this requires
   the server to track a single last-invoked time and to self-terminate
   when the time of the longest lease has elapsed.
   
In either case, the server must either:
a) instrument *every* method call so that the last-invoked time is updated
   (best done generically via a smart proxy mechanism supported by some ORBs,
   perhaps also in ORBit); if ORBit can't do smart proxies, then an object
   implementation must update the object's last-invoked time manually

b) implement a renew_lease() or ping() method that clients use "every so often"
   to remind the server that they still need the service
   
I would argue that Bonobo ref-counts are more trouble than they are worth
if the server can use an idle-timeout or a client-supported lease renewal
mechanism.

Colm.

>- Dietmar
>
>
>_______________________________________________
>gnome-components-list mailing list
>gnome-components-list gnome org
>http://mail.gnome.org/mailman/listinfo/gnome-components-list