Jim Starkey wrote: > Jay Pipes wrote: >> Jim Starkey wrote:
[snip] > Necessary? It isn't. Nothing is necessary. A database can be a simple > store/fetch with no added value. It's faster, of course, is databases > can do selective retrievals, which requires comparisons. And it's > useful if database systems can differentiate between string, numbers, > and dates so it can do useful comparisons. And it's useful if database > systems do joins to eliminate the number of round trips to get required > data. It's also useful for databases to do arithmetic so they can > handle more complicated queries, and so on and so forth. > > The point is that all of this complication is useful: It allows the > database system to do, the client to do less, the amount of data > transfered and the number of round trips to go down. [snip] > I don't expect anyone to agree with me, but I > believe that a strong architecture that supports encapsulated extension > is a better way to do things. In specific, I think that supporting > loadable C or C++ is a terrible idea. I went there in the 1980's with > Interbase and regretted it. Even if you have decent APIs (and drizzle > doesn't), there is still the security/reliability problem of loading > untrustworthy code. These issues have been dealt with in languages like > Java, but are unsolveable in C and C++. C/C++ APIs is a base for building systems to support whatever language you choose. Ideally, it should be possible to build the system to support extensions written in Java, Lua, Clean, SELF, Forth, whatever; but to do that, it is essential to have a working C/C++ API into the server. The API need to be there anyway, for pure engineering reasons, so it is just decent to put a little extra effort into ensuring it is stable and documented and let anybody extend it with modules of their liking. If you feel like adding a Java loader module, feel free to do it (actually, I would encourage and support it, for the reasons you mention), but to do that, a C/C++ interface is needed, so it might just as well be an API proper. > I think drizzle would be way ahead of the curve if it support a > theoretically defensible way to permit encapsulated extensions of user > semantics than by either supporting hundreds and hundreds of special > case hacks or allowing j-random code to run loose in what would > otherwise be a trusted server. That is actually a decision that the DBA should make, not Drizzle. Drizzle should just provide the tools to do what is necessary. Just my few cents, Mats Kindahl -- Mats Kindahl Lead Software Developer Replication Team MySQL AB, www.mysql.com
begin:vcard fn:Mats Kindahl n:Kindahl;Mats org:Sun Microsystems adr;quoted-printable:;;Tegv=C3=A4gen 3;Storvreta;SE;74334;Sweden email;internet:[EMAIL PROTECTED] title:Lead Replication Software Developer x-mozilla-html:FALSE version:2.1 end:vcard
_______________________________________________ Mailing list: https://launchpad.net/~drizzle-discuss Post to : [email protected] Unsubscribe : https://launchpad.net/~drizzle-discuss More help : https://help.launchpad.net/ListHelp
