Subject | RE: [Firebird-Architect] Re: Encryption for embedded server |
---|---|
Author | unordained |
Post date | 2004-09-28T21:26:39Z |
"As Jim described it, a plug-in would be required for base functionality -- that's just wrong."
Some of us might politely wish to take an alternate view: anything that can be a plugin (even
default functionality) should be. I would have no problem with firebird having no default functions
whatsoever, requiring me to load UDF's to get even the most basic functionality. I also wouldn't
mind an engine that was i/o-agnostic, requiring a default plugin for that. Same for security. And
datatypes. I don't care that it "doesn't do anything" by default. My girlfriend's food processor
doesn't "do" anything either without an attachment on it -- heck, it even refuses to spin the
motor. (Smart food processor.)
Yes, it's a pain to setup the first time. But it's also cleaner -- defaults don't get more access
than alternatives, they require the same interface thus forcing the it to be more complete, there's
only one set of failure points to check for.
It also means you don't get stuck (datatype-handling, for example) with a bunch of SWITCH/CASE
statements in the code. Just because it's a good default doesn't mean it shouldn't be abstracted
out into a plugin. (Have I mentioned that I wish all datatypes were purely plugins, with -maybe-
support for some sort of boolean-ish operations at the engine level, mostly for constraints?)
If you're talking about replacing functionality, use plugins. If you're talking about
monitoring/logging activity, or if (like apache) you need to modify a request/response along the
chain, that's more like callbacks. There's room for both -- but callbacks probably shouldn't be
expected/allowed to interrupt a chain, completely change what's going on, and act as their own
entire "thing" ...
-Philip
---------- Original Message -----------
From: "Leyne, Sean" <Sean@...>
Some of us might politely wish to take an alternate view: anything that can be a plugin (even
default functionality) should be. I would have no problem with firebird having no default functions
whatsoever, requiring me to load UDF's to get even the most basic functionality. I also wouldn't
mind an engine that was i/o-agnostic, requiring a default plugin for that. Same for security. And
datatypes. I don't care that it "doesn't do anything" by default. My girlfriend's food processor
doesn't "do" anything either without an attachment on it -- heck, it even refuses to spin the
motor. (Smart food processor.)
Yes, it's a pain to setup the first time. But it's also cleaner -- defaults don't get more access
than alternatives, they require the same interface thus forcing the it to be more complete, there's
only one set of failure points to check for.
It also means you don't get stuck (datatype-handling, for example) with a bunch of SWITCH/CASE
statements in the code. Just because it's a good default doesn't mean it shouldn't be abstracted
out into a plugin. (Have I mentioned that I wish all datatypes were purely plugins, with -maybe-
support for some sort of boolean-ish operations at the engine level, mostly for constraints?)
If you're talking about replacing functionality, use plugins. If you're talking about
monitoring/logging activity, or if (like apache) you need to modify a request/response along the
chain, that's more like callbacks. There's room for both -- but callbacks probably shouldn't be
expected/allowed to interrupt a chain, completely change what's going on, and act as their own
entire "thing" ...
-Philip
---------- Original Message -----------
From: "Leyne, Sean" <Sean@...>
> The approaches you describe are fine, I support them completely, but------- End of Original Message -------
> would be the functionality added by the plug-in(s).
>
> As Jim described it, a plug-in would be required for base functionality
> -- that's just wrong. A Plug-in should only be required if you want to
> change/enhance the built-in/inherent engine functionality/security.
> They should not be required to define the 'base' install.
>
> To install an engine I should not need to provide any plug-in, that
> should be an option, not a requirement.
>
> Sean