Hi! On Thu, Feb 26, 2009 at 4:35 AM, Jim Starkey <[email protected]> wrote: >> A good thing. If you want to change the interface, you have to go and >> understand and fix every single use of it. Encourages people to rather >> quickly get it right.
My fear is this will lead to about as many interfaces as there are developers that can think of new plugin types. Maybe nice if you like to buy in now and grow up with this project, not so much if you want to 'quickly' extend it later on when the core is more or less ready. I fear you will see a lot of one-man shows that know how whatever plugin they are committed to works. > > Stewart, that hasn't been my experience with the storage engine interface. > Quite the contrary. About three times a week somebody makes an arbitrary > change without any investigation, and everyone gets jerked around. This is a nice example. I can't complain that I have been jerked around by it as I was never professionally involved n creating a storage engine. But I did try for hobby, and it's just unbelievable how little documentation there is. Basically it's impossible to create an SE unless you have access to server devs, and they are willing to exchange emails or do some handholding through IRC. Now I have always met many people friendly enough in this aspect, but my point is this type of exchange of knowledge just does not scale. Also, On many occasions, experts in the field respond to questions with "Just read the code, it's all there". In subtitling, that reads "Look, I don't know either, *I* would be reading the code until I would get it". This may be fine if your life depended on it, or if you are a server dev by profession, but I don't think this should be exemplary for a piece of software that should be extensible by design. I'll gladly accept that it takes an investment on the programmers part to learn something new. But really, everything you need to know about writing a plugin should be documented so people can do selfstudy for about 80%-90%. To achieve that, it should actually be documentable. That is, it should be stable enough so it can be written down and read before everything changes again and it should make enough sense so people can understand it and still feel happy about giving it a go themselves. In MySQL, arguably only the UDF interface comes close to this level (not saying its a good interface - just saying it is stable and close to simple), and even that has many gaps in the documentation, many features known to just the implementer then and then, since that and that server version. (sorry for the rant. disclaimer, this ^ all pertains to MySQL perhaps its better now in drizzle. But so far I have seen little drizzle discussion threads on internal interfaces, other than that someone '..added a few hooks here and there...'. I mean, considering the MySQL basis and the ambition to do things better I expected to see more of those. Maybe I'm completely wrong in which case I apologize, but then I would appreciate it if somebody could point me to specific examples of how drizzle plugin interfaces) kind regards, Roland > > Perhaps, just perhaps, if people thought they had to live with a design, > they might learn to think about the requirements, the design, the likely > modes of change, etc. > > Loosy-goosy is a design principle, but not necessarily the best or the most > enduring. > > A meta-design that encourages forethought has a certain merit, don't you > think? > > > _______________________________________________ > Mailing list: https://launchpad.net/~drizzle-discuss > Post to : [email protected] > Unsubscribe : https://launchpad.net/~drizzle-discuss > More help : https://help.launchpad.net/ListHelp > -- Roland Bouman http://rpbouman.blogspot.com/ _______________________________________________ Mailing list: https://launchpad.net/~drizzle-discuss Post to : [email protected] Unsubscribe : https://launchpad.net/~drizzle-discuss More help : https://help.launchpad.net/ListHelp
