Alexey Parshin wrote:
1) SPTK was never aiming to embedded devices. If you want to do it - we can create a different toolkit with totally different approach. Once again, that STL crap I'm using should never be in embedded toolkit.
We will have to work on it. STL performance shouldn't be worse.I trust you it is now, but I think we can do some trickery to make it better.
It's next somewhere on my TODO (not right away though).
2) Having database API is a plus - not a disadvantage. If user doesn't want to use it - that's fine. If not - he can exclude it by defining it in configure. If you want to make it smaller - we don't have to divide the library. We just have to exclude unneeded parts.
Maybe.. This argument works for embedded devices (sort of). Butdoesn't it insult your aestetic feeling to link with -lspdb3 to get CThread class
in?
Not nessesarily. Say he installed SPTK3 and SPTK3-dev RPM (I sure hope one day it'll be bundled with distros), and he is using DbToolKitXZZY for his db access in his CPPSERV servlet. If CPPSERV servlets require libspdb3 for CThread, and libspdb3 has CDatabase class in it (because vendor wanted fullest RPM possible), end user will get3) If someone has same classnames as SPTK _AND_ he has compiled ODBC in SPTK - was to bad because he's probably an idiot. At least, some mental problems are presented.
load-time dynamic linker failures.
Oh, but we also have very easy access to databases - just use any of hundreds of toolkits available to C/C++ writers. Like I said previously, I love the fact that SPTK provides nice database connectivity layer. I just don't want to force it on users (speaking of which - PHP is also very popular, because it provides all sorts of different database access tookits, notBTW, one of the secrets of popularity of PHP (the best web tool, imho) is a very easy access to databases.
single generic one).
2005/9/29, Ilya A. Volynets-Evenbakh <ilya@total-knowledge.com>:"Business usage" Think web GUI in embedded appliance with _very_ limited resources. Think about having 32M of RAM as luxury. These aren't some random numbers I pulled out of my ass - most low-end routers nowdays have that kind of resources. Currently web GUI for devices like that are some sort of CGI scripts - which isn't very nice thing to program. Java API is lot better - but running java on such device is clear overkill. CPPSERV is ideal use, yet, there is no need for database - all such thing would need is access to XML API. BTW, CPPSERV itself should never aim at providing database API, nor should directly link to any particular one. Instead, it's decision of servlet writer. Yes, we could (and abviously you do) provide database access API alongside, which integrates nicely into it, but we shouldn't force it on end userd, because, let's face it, there are far more programs out there that are not using SPTK for database, then those that are. Which is yet another reason to unbind utility classes from database classes. Imagine what would happen if someone wanted to write a servlet using database API XZZY that also has classes named CQuery and CDatabase in it... Alexey Parshin wrote:Every bit aint matter for the last 10yrs (I don't know where have you been all this time). There is no useful application these day that isn't using databases. At least, in business. The dependencies are cut-off with configure. If SPTK has something that you need to exclude - offer more options in configure instead. Just remember - SPTK was designed mostly to provide GUI+DB. If you can use it for something else - that's fine. In CPPServ, for instance - you'd need to provide database access, otherwise its business usage is very limited. 2005/9/29, Ilya A. Volynets-Evenbakh <ilya@total-knowledge.com>:Problem 1: Loading of unneeded code (I'm thinking embedded here)For embedded you need something much better using memory than SPTK. I sacrificed the efficiency of old SPTK classes to the standards of STL :(Problem 2: Dependancy on unneeded tools (partially solved when you separated GUI and database)Yes, and if we have anything else here - lets discuss it. Doesn't make much sense, though. 99% Windows and many Linux machines already have everything to install full-blown SPTK. If not - than we are talking about some home machine, and it's not clear for me what SPTK is doing there :)Problem 3: ReadabilityCome on :) Same classes would be groupped differently?In case of CPPSERV, there is no need in any database-related stuff, butThat is a mistake. If you really want people to use it of'course. Just imagine someone who isn't happy with anything else but CPPServ - and not using database? That's funny :)I can make good use of most of other utilities (Registry, XML, Threading).I understand that part.Now, if I ever decide to use it in embedded application, every bit will matter.I don't beleive in STL usage for embedded devices. STL is wasting memory and application size like crazy. It's also slower than regular classes, even if they require more work.-- Ilya A. Volynets-Evenbakh Total Knowledge. CTO http://www.total-knowledge.com-- Alexey Parshin, http://www.sptk.net
-- Ilya A. Volynets-Evenbakh Total Knowledge. CTO http://www.total-knowledge.com
List hosted by Total Knowledge