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. 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. 3) 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. BTW, one of the secrets of popularity of PHP (the best web tool, imho) is a very easy access to databases. 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: > >>Readability > >> > >> > >Come on :) Same classes would be groupped differently? > > > > > > > >>In case of CPPSERV, there is no need in any database-related stuff, but > >> > >> > >That 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
List hosted by Total Knowledge