> And there are IDEs like eclipse that do a lot of the grunge work > boilerplate for you, and maven to manage components as you scale up. eclipse froze my first FC4 tryout ... is for me what BerkeleyDB is for you. > > I do agree personally - I can't think in java and do much better when > you can squeeze the logic of a routine onto one page where you can see > it all at once. > ..... > I'd relate the importance of code size to the amount of RAM you can > afford. For a long time now it has been cheaper to buy RAM than to > hire someone capable of shrinking your code base - unless maybe you > have a mass-market application that will run on millions of boxes. By 'size' I was actually referring to 'source size' : (1) you say it above "..[all micro] logic..[on] one page ..". (2) the same idea but in a project-macro-logic sense viz a viz sheer quantity of code lines to manage overall. I do rate java for designing GUI-interfaces. No argument there. GUI components ARE objects. But most of the real world aint ..(malfits being the reason for extensibility in OOP).. and it turns out I think that re-usability mostly goes hugely custardly. (And aside, if best programming is the truly 'creative' kind, not just spending time finding the right lego blocks to make new combinations with, then OOP fits badly anyway). > >>>> Why BerkeleyDB? I dont know of an embedded-db equivalent that will >>>> store >>>> 'any and every data exactly as is'. >>> >>> I'd think sqlite first - these days anyway. > > You can always do input into temporary tables structured more like the > input data and process to normalized form later (if needed). Not if normalising implies any user-interactivity (the usual scenario). An early input in the automated background input stream off the wire generates some KEY which a later input of the same stream hours later may try to match against. Would the latest sqlite accept a KEY that was say (& maybe badly) both QP-encoded and HTML-encoded, and even if it did so now would that be guaranteed to endure through future versions of those encodings without ever rejecting? Even if the 'normalising' could be automated satisfactorily to avoid all rejections for sqlite right now within the capture process, it would be biased to sqlite's constraints, an unwanted extra layer that may well also actually corrupt the heavy duty (search-engine)-normalising already being performed on difficult data ..(eg stemming, scoring, indexing). In a sense, BDB serves the "temporary tables" suggestion already, but so much more as to be sufficient in itself. You seem unduly anti-BDB? Quite frankly I have had far less trouble with it than any other db ever. In the past year I have had to do one dump/(re)-load [about 1 hour], and twice delete the environment files [about 1 minute] so that they would self-rebuild on next access. That's it! Which doesn't mean I'm not also always open to suggestions. > > Sqlite should be equally usable - and easier to convert to/from server > backends. That might not have been true long ago, though. >>> If you had moved to Centos3 as the first step, you could have run that >>> with nothing more drastic than a periodic 'yum update' for years, then >>> jumped to Centos5 with no rush to change again even now. >> Ah, now you tell me! > You should have asked sooner. I still have a few centos3 boxes going > strong. I had problems with perl modules and a few other things in the > early stages of centos4 and skipped over that for most systems. And proves that the time I can make available for discovery falls short by heaps. Nearing closure on a very long project right now, thinking ahead to next steps, reviewing the robustness of past decisions, is very enjoyable and an unusual luxury for me. Playing the 'distro-hopping' game that many seem to indulge in for instance has just been out of the question. I have some processes shared with win boxes over RPC (producung excel charts) which require that both Perl version and versions of modules like Storable.pm exactly match, so am largely at the mercy of what the Activestate repo provides as to what must be run on the linux box too. I need lots of browsers too (alongside Firefox) for day to day work. The old versions of Mozilla, Konqueror and Opera which will run under FC4 are critically dysfunctional on some operations needed. So am looking to try a more up to date team. CentOS is beginning to look more & more like my cup of tea, and since I gather that a new major is immanent maybe it will support the new Google Chrome (along with Seamonkey, Opera-11+)? I wonder if there is a list of packages somewhere. If the repo web-page for CentOS provided the actual repo-address I was going to try direct my FC4-yum there for listings, but cannot seem to find it. It may be still the case that I cannot have 'both worlds' on one box, or maybe I can try a CentOS + VM-XXX configuration.... hmmm. Sean