[ZODB-Dev] Re: ZEO signal feature

[Toby Dickenson]

On Tuesday 24 Sep 2002 4:21 pm, Jeremy Hylton wrote:
> >>>>> "TD" =3D=3D Toby Dickenson <tdickenson@geminidataloggers.com> wri=
tes:
>
>   TD> I think of it as a mechanism to extend the Storage interface.
>
>   TD> (RPC is a detail of how ZEO happens to implement the signal
>   TD> method)
>
> Wouldn't it be more natural to extend the storage interface
> dynamically by adding new methods?  The interface has evolved over
> time using this approach, e.g. transactionalUndo().  The (optional) ZRS
> methods like restore(), lastTransaction(), etc. are also implemented
> this way.

So the ClientStorage instance gains an extra method attribute, purely on =
the=20
basis that it is connected to a storage server using a storage which decl=
ares=20
he has an extension method.=20

That scores high for being natural and pythonic, but loses points for=20
polluting ClientStorages instance namespace.

Further, ClientStorage needs to declare that it implements a set of exten=
sion=20
methods which is the union of the underlying storage's extensions plus it=
s=20
own extensions (if it has any, see below). Again, thats not hard, but it =
is=20
work.

Im sure there are no fatal flaws with either approach. I dont really mind=
=20
which approach is used.

> This raises an interesting question for me: How would anyone invoke
> extension methods on the storage?  ZODB application software isn't
> supposed to interact with the storage directly.  It's supposed to use
> the DB and Connection objects.

Yes, this is only for clients that have special knowledge about the type =
of=20
storage they are dealing with. For example DirectoryStorage has a Zope ob=
ject=20
which adds extra management controls for its snapshot mode.

I can only guess at what a 'ZRS' might be, but I dont suppose it goes thr=
ough=20
the DB and Connection objects either.
=20
>   TD> 2. Suppose ZEO gains an extension method in the future. It will
>   TD> be easy to understand how it should consume some extension
>   TD> methods itself, and pass others on.
>=20
> The ZEO protocol already has enough flexibility to accomodate
> extensions without creating any confusion about whether a message is
> intended to invoke a method.  The flags slot in the message allows
> pretty arbitrary out-of-band messages.

I didnt mean an extension to the ZEO protocol, but rather an extension me=
thod=20
on the ZEO storage. For example, a method to determine the instantaneous=20
client cache hit rate.=20