[omniORB] Re: Connection Handler

[Renzo Tomaselli]

Hi,
	why not using contexts to avoid an extra parameter on each IDL call ?
Identifying the client sounds much like identifying the principal for
security reasons or identifying the current transaction for other purpose=
s
(the implicit way). Since the connection is out of this game, it seems to
me that the client is the only subject enabled to specify its own identit=
y
as thread/process/host or whatever else. From long time ago discussions o=
n
this list about contexts, I remember they weren't much welcome; however
having a client identity/principal identity/transaction control as extra
parameters in each call would be terrific.
Comments are much welcome,

		Renzo Tomaselli     =20
-------------------------------------------------------------------------=
--
TecnoTP s.n.c. Special Information System Design
Maso Pelauchi I38050 Ronchi Valsugana,  Trento TN  ITALY
Tel. +39 0461 773164      Fax. +39 0461 771514
e-mail: renzo.tomaselli@tecnotp.inet.it  =20
-------------------------------------------------------------------------=
--

----------
> From: Dietmar May <dcmay@object-workshops.com>
> To: 'Myles Penlington' <myles@ams.co.nz>; 'Armen Yampolsky'
<ayampolsky@erols.com>; omniorb-list@orl.co.uk
> Subject: RE: [omniORB] Re: Connection Handler
> Date: gioved=EC 7 gennaio 1999 16.49
>=20
>=20
> Now, if only we could get the ORB to do this, perhaps changing the IDL
compiler=20
> to call thru a function pointer (if set) in every dispatch() method ...
we=20
> might have something like Armen was originally asking for. (It avoids t=
he

> tediousness (as Stroustrup puts it) of repetitive code - and the
accompanying=20
> propensity for errors).
>=20
> Now, the question is whether there is a unique handle for each client
that=20
> could be used automatically (obviously not the socket handle), or does
the=20
> client have to explicitly pass in a server-assigned handle as a paramet=
er
to=20
> each IDL call? ie. is it possible to uniquely and unambiguously identif=
y
a=20
> client based on connection parameters, given the abilty (and need) of t=
he
ORB=20
> to shut down and re-open connections?
>=20
> Dietmar
>=20
>=20