Subject | Re: [Firebird-Architect] Re: Database Capabilities |
---|---|
Author | Nando Dessena |
Post date | 2005-07-23T08:15:31Z |
Jim,
then you should perhaps have started by describing the problem instead
of throwing in a detailed solution inclusive of the binary layout of
the required structures. IOW, I think you should have done as you
frequently preach others to do. :-)
Thanks for fixing this by disclosing this info.
Anyway, I am not sure I see the problem even now (I might just be
thick).
J> There is currently a good
J> possibility that the first Vulcan release will precede Firebird 2.0,
J> though Firebird 2.0 may have more capabilities. There simply won't be a
J> linear ordering of releases.
not to mention that some people (meaning some connectivity tools
makers) might want to still transparently support InterBase as well.
J> Jaybird needs to know about
J> engine/database capabilities, but can't possibly know about what future
J> point releases will make those capabilities available.
I assume Jaybird will have to be updated anyway to support future
capabilities. Or are you implying that there are capabilities about
which Jaybird knows about already, but it's not known which Fb/Vulcan
version implements them? If this is the case, then relying on the
version string won't work, but neither your scheme would.
Note: lately I have been implementing a scheme that's exactly what you
propose for one of my c/s systems; previously a version string check
was used, so you can see that I'm not against your proposal in
principle: I just can't see what problem it solves in Fb as clearly as
I did in my app's case.
J> Version strings
J> can tell you about the past; Capabilities are necessary to handle the
J> future.
Capabilities are more elegantly extensible, but you can handle the
future without them pretty well I believe. Plus, the proposal does not
address the problem of knowing the capabilities for a database that
doesn't exist yet. Who should I ask whether I can create a dialect 3
database or not?
Ciao
--
Nando Dessena
http://www.flamerobin.org
>>I agree; it appears that either this is a solution looking for aJ> Not true. The problem is real and immediate.
>>problem or at best a problem that's not very urgent.
then you should perhaps have started by describing the problem instead
of throwing in a detailed solution inclusive of the binary layout of
the required structures. IOW, I think you should have done as you
frequently preach others to do. :-)
Thanks for fixing this by disclosing this info.
Anyway, I am not sure I see the problem even now (I might just be
thick).
J> There is currently a good
J> possibility that the first Vulcan release will precede Firebird 2.0,
J> though Firebird 2.0 may have more capabilities. There simply won't be a
J> linear ordering of releases.
not to mention that some people (meaning some connectivity tools
makers) might want to still transparently support InterBase as well.
J> Jaybird needs to know about
J> engine/database capabilities, but can't possibly know about what future
J> point releases will make those capabilities available.
I assume Jaybird will have to be updated anyway to support future
capabilities. Or are you implying that there are capabilities about
which Jaybird knows about already, but it's not known which Fb/Vulcan
version implements them? If this is the case, then relying on the
version string won't work, but neither your scheme would.
Note: lately I have been implementing a scheme that's exactly what you
propose for one of my c/s systems; previously a version string check
was used, so you can see that I'm not against your proposal in
principle: I just can't see what problem it solves in Fb as clearly as
I did in my app's case.
J> Version strings
J> can tell you about the past; Capabilities are necessary to handle the
J> future.
Capabilities are more elegantly extensible, but you can handle the
future without them pretty well I believe. Plus, the proposal does not
address the problem of knowing the capabilities for a database that
doesn't exist yet. Who should I ask whether I can create a dialect 3
database or not?
Ciao
--
Nando Dessena
http://www.flamerobin.org