|The MulleSybase EOAdaptor Technology Demonstration
(updated 23. March 2001)
This is a snapshot of the ongoing development of the Mulle kybernetiK Sybase Adaptor. The demo is solely there to show people that a working and production useable EOF Sybase Adaptor for Mac OS X Server is feasible outside of Sybase/Apple and also to get feedback on the direction this project should take (see below).
Feedback so far has been one person, who showed interest in the adaptor. Judging from this "market surveillance", I have nothing to lose to keep this more of a demo project than some offical/commercial endeavour. Because of the general lack of interest the adaptor will probably not see a public release very soon (i.e. think months, instead of weeks). It will be used in a commercial project though, so it definetely will be finished.
Anyway the current state is this: Because I was not very happy with the FreeTDS implementation I am now writing a TDS/CT replacement, which allows me to do all sorts of nifty optimizations and lets me address all if not most issues in the disclaimer. At the moment the adaptor fetches as the terminus technicus is "like a screaming mother" but insert/update delete are still very slow, because they are done without bind variables. This will be the next step to implement.
Not using FreeTDS has the unwanted side effect, that the MulleSybaseEOAdaptor will lose compatibility to SQL Server and older sybase products, since it is implementing TDS 5.0. ASE 11.9 works :)
For ye olde demo coderz: Performance wise, the adaptor is now responsible for approximately a third of the total time spent fetching rows. The rest is used up by the EOF. Of that third, only a tenth of the time is actually spent reading from the socket, whereas about two thirds is used up for allocation and autorelease (and there mainly the NSDictionary (ca. 25%)). Even with a final amount of optimization (I have some plans <grin>), the adaptor can not become much faster than 20% of its current speed, if staying single threaded. With optimal threading one could get 30% better. I am afraid that's about it.
Wanna alphatest, when its ready ? Send me an email.
I am sneakily putting this text here in the middle of things fully expecting noone to notice. Basically the adaptor is done - alpha state. Solaris should work, I should fix it up for NT sometime, but that can wait. So i will just ramble on a bit about things. Last weeks were spent implementing the bulk copy routines for the image/text. That wasn't so hard to do, but left a small wart on the design I think. I finally got around to profile raw row fetching performance and I seem to have hit the point, where there is no more room for optimization. If I could implement my own NSZone I could probably get a massive performance boost, but that is now out of the question (because currently you can't do that). The other possibility would involve to completely reimplement NSString, NSDecimalNumber etc.. Foundation Classes, but I am frankly too lazy for that. Chris Kane gave me a hint that in MacOSX I could implement my own malloc/free stuff, so if that is true and works like I hope it will, expect big things to come.
Actually I cheated on the bind variables, though the code is there to do 'em, currently only image/text are done with bind variables, and these special bulk binds are handled differently. The parameter code for using bind variables is in place, but so far I had little incentive to really implement it.
Since David Knight put the adaptor thru some tests, it became clear at which places the adaptor was still lacking. So I just want to list a few of the improvements, that have appeared.
I would consider the adaptor to have reached beta stage. There are some known bugs and a few missing features, but nothing substantial is missing. Availability to the public is still a big unknown though
Now comes of course the big question ? How do you get the adaptor ? The answer mail me and we will see. Make me an offer I can't refuse. I am still not sure what to do with it. I am starting my own company in a few weeks and we will use the adaptor there. Maybe it will be a proprietary business model.. we will see.
This software is in no way fit for serious development or (shudder) even deployment. This is not alpha, this isn't even pre-alpha. These are some of the known problems of this technology demonstration
Anyway Feedback is welcome and should be sent to email@example.com
You need to download and install two packages. There is the package for the adaptor. You also need to download the FreeTDS Framework package to provide the ct_lib library. You can get the source for FreeTDS at www.freetds.org. The FreeTDS framework is missing some routines that the MulleSybaseEOAdaptor doesn't need currently (like f.e. the bulk stuff).
Where is the source ?
This preview of the MulleSybaseEOAdaptor uses FreeTDS as a ct_lib replacement. FreeTDS is neither complete, nor bugfree. It also does not seem to be the very best implementation and has the general problem of being a LGPL product. Reading the license, I am of the opinion that my adaptor is not also automcatically subjugated under the LGPL, and your code that links to the adaptor and implicitly FreeTDS can therefore be as commercial and non-open source as you wish. But your lawyer's opinion might differ.
Licensewise I have three options:
What's your opinion ? Mail me at firstname.lastname@example.org