Problem 1: Loading of unneeded code (I'm thinking embedded here) Problem 2:Dependancy on unneeded tools (partially solved when you separated GUI and database)
Problem 3: ReadabilityIn case of CPPSERV, there is no need in any database-related stuff, but I can make
good use of most of other utilities (Registry, XML, Threading).Now, if I ever decide to use it in embedded application, every bit will matter.
Alexey Parshin wrote:
Basically, what is the problem you're trying to solve by lib separation? That is the question I should ask from the beginning 2005/9/29, Alexey Parshin <alexeyp@gmail.com>:You can't use most of utilities without the core spdb classes. And I don't really see any point or gain in separation. These libs aint too large, and I'm going to make the smaller. I went from one lib to several by negotiating with a bunch of different people, and don't want to touch it anymore.. 2005/9/29, Ilya A. Volynets-Evenbakh <ilya@total-knowledge.com>:Well, OK - fine on SPTK (and I guess we have to make --enable-fltk dependant on --enable-odbc). I still think we need to separate utilities out, since they are usefull by themselves, and there might be projects that will benefit from utility classes, while not needing database - I guess you don't want them to load extra stuff into memory, if they don't need to? ;-) Alexey Parshin wrote:That is one thing you're not getting. In SPTK, all the gui components depend on DB stuff. And I don't really care if -lspdb causes anybody any associations. It's just a name. Alexey 2005/9/29, Ilya A. Volynets-Evenbakh <ilya@total-knowledge.com>:I agree - that we may not want to have too many of them. However, being able to separate generic utility from non-generic libs would be fine. More, currently, you _must_ have spdb in order to compile sptk, since many of sptk classes are tied to CQuery. I don't know if it makes sense to separate them in this case. Right thing to do I guess would be to have DB-dependant GUI, and DP-independant GUI separate. (I presume you actually have DB-independant GUI) actually, it would be OK to have spdb and sptk as is, as long as no database related classes would be compiled when --disable-odbc is used. As for sputil stuff - it's just for clarity, because having to link with -lspdb3 when you are not using database feels just wrong. Alexey Parshin wrote:So, we need a separate libs for : 1) Threads 2) DB 3) XML 4) ... Please, be reasonable. This is working just fine. If someone doesn't need XML or DB - he can always define it in configure. I really don't want to multiply these libs. 2005/9/29, Ilya A. Volynets-Evenbakh <ilya@total-knowledge.com>:So, I looked at SPTK, and think one more large change needs to be done: we need to separate utility classes and database classes. I propose that we create libsputil3 library, that will have things like CDateTime, CThread, etc. Only question here, is wether we should separate XML stuff as well, or just live it in util library. -- 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-- Alexey Parshin, http://www.sptk.net-- Ilya A. Volynets-Evenbakh Total Knowledge. CTO http://www.total-knowledge.com-- Alexey Parshin, http://www.sptk.net-- Alexey Parshin, http://www.sptk.net
-- Ilya A. Volynets-Evenbakh Total Knowledge. CTO http://www.total-knowledge.com
List hosted by Total Knowledge