On 7 Oct 2004 at 11:58, Jim Starkey wrote:

> The test of an architecture is to invent plausible new requirements and
> see if they can be accomodated.

Ok, but your spec is more a sketch than complete RFC, so it's a little
bit harder to get a handle on it for us less experienced. Well, let me
try again to get into it.

If I understand you correctly (and please correct me if I'm wrong), you
propose that for our purposes the SP is just a SP, which means that it
must support only very basic, general plug-in interface, and the engine
doesn't make any assumption about its purpose or additional interfaces.
These additional interfaces and real purpose of plug-in is defined by its
use specified by configuration (i.e. context). So far, so good, as SP can
implement interfaces needed to act as an authentication plugin along with
other interfaces to act for example as encryption one etc. because there
really is no need to force the plug-in to have only one
purpose/interface.

Because is impossible to define beforehand all configuration attributes
that particular SP may require as they would depend on implementation,
config manager (or whatever code would be responsible for that) must
handle arbitrary attributes for SP's, and to make configuration more easy
for admins, in cascading way.

There could be multiple references to single SP in config, and an
arbitrary number of SP's could be defined (and hence active in a chain)
at a time for any particular config "node" (db, engine, server).

If it's really as described above, then I like it a lot. This basic idea
is very simple but very flexible. Unfortunately, there are some points in
your spec that are not clear to me.

What's not clear from your spec is how many chains and at what levels
there could be. Chain of SP instances reflects the particular set of
configuration values, so if there could be various configuration chains /
cascades simultaneously applicable on a running system, there definitely
must be more chains of SP instances (or am I wrong ?)

I guess that each active database would definitely have it's own SP chain
(at lest I read your spec that way). But is it possible for server or
engine to have its own chain (that doesn't extend to db level) ? It may
make sense. For example server may have wire comm. encryption SP, and not
all server comm. is tied to active db attachment, so db level chain can't
be used.

It's also not clear how particular SP chains will interact, if ever, but
I can imagine that chains at different levels (db, engine, server) would
need to interact in some way.

Next in the pipe is how FB code calls SP's...

If I understood you correctly, a SP chain can contain SP's of different
types (even those that are not yet invented), hence with different
interfaces. Is not clear from your spec how it's supposed to be handled.
A detail, of course, but IMO very important one. We can't use one big SP
interface enhanced with new calls whenever we come up with new SP type or
fix old one. When SP's would support COM interfaces or similar method of
introspection, then they could be handled by single chain very easily,
but there are other possibilities. Pure class hierarchy should work too,
but multipurpose SP's would need to use multiple inheritance, and I'm not
sure how good it would work with late binding and dynamic libraries as
i'm not a C++ developer. Would be nice to know what method you have in
mind.

Sidenote: That bring us to your proposed general interface for SP. There
is IMO no point to place userInfo and updateAccountInfo into general SP
interface as they belong to authentication SP interface, or did I miss
something here ?

What is also important to know is how connection between calling code and
SP would be handled. Well, there is a chain of SP's where called SP pass
the unhandled call to next one, but is it practical to do that on every
call ? I think that in many cases it's not practical, because once the
responsibility who will handle the call is sorted out, there is no gain
to do that again until context changes, so direct binding to particular
SP entry point is beneficial. Of course, it's acceptable behavior for
authentication SP, as they are not called often, but how about encryption
SP ? Going up te chain whenever page is read or writed doesn't look like
a good idea.

Because direct binding on method level is unpractical, some rules must be
defined to make a compromise between flexibility and performance. I would
suggest that SP must respond to all methods of particular interface, i.e.
it can't handle only some calls and pass others from the same interface.
If this "fixture" is not desired, then we should introduce (or enhance) a
SP info call in which SP would declare its behavior beforehand (if I will
handle some call from this interface, i will or will not handle all
methods from this interface), so direct binding would be possible at
least per case basis.

Here is also the point where the idea of Security Manager comes into play
again. SM would act as a single point of call from code to whole SP
chain. It can handle the pass the call around or direct binding
transparently (among other thing).

Best regards
Pavel Cisar (ICQ: 89017288)
http://www.ibphoenix.com
For all your upto date Firebird and
InterBase information