Subject Re: [Firebird-Architect] Re: Vulcan services engine info
Author Jim Starkey
Arno Brinkman wrote:

>It would be nice if Jim will react in this discussion, but unfortunately i'm afraid he doesn't :(
>
>
>
I'm here and paying attention. The discussion was going nicely and I
didn't think it needed intervention.

There is nothing wrong with a provider making calls back into the
Y-valve through the proper, documented API provide that honors the
"opaqueness" of handles. So both you and Roman are correct -- calls go
only down the chain, but the dispatch modules can appear in the chain
more than once. I trust that everyone understands that an infinite
recursion isn't going to work very well.

The dispatch module is indeed a provider for two reasons. First, it was
the easiest way to build the beast. Second, my gut said it was the
right way to do it. My gut has a pretty good but not perfect track record.

It your architecture now, not mine, so while I'm perfectly willing to
answer questions, I'm not steering anymore.

Just a few words of advice. A dumber dispatch module is better than a
smart one. Having it poll and aggregate subsystems is about as smart as
it ought to get. If you need to extend the provider interface, do it --
that's what it's there for. Just be sure to kick up the interface
version number when you do it.

--

Jim Starkey, Senior Software Architect
MySQL AB, www.mysql.com
978 526-1376