On 12/20/10 4:56 PM, Sean wrote: > > 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. Agreed, but long term the main thing is that you can trust the components you've used not to change interfaces and make you re-visit them once something is working. If you can treat something as a black box and trust it, the size of the component isn't that important. >> 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). Normalizing is for database efficiency and reducing redundancy and usually doesn't relate well to the set of information a user would have at once anyway. > 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? I'm not sure how the database involved matters for that. Or why you wouldn't fix it at the first opportunity. > 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! I suppose I hold a grudge longer than necessary. Long ago I inherited a bulletin board system that held user data (login/password/read message list) in a bdb. It had been put in production but the author left before the 'read lists' grew to a point where a bug in bdb made them regularly overwrite random adjacent data, including other people's accounts. It was not a fun experience. Also, you might note that subversion was originally released with bdb as the default backend storage. It isn't now, due to regular problems - although those were probably file locking/sharing issues in multiuser use more than anything else. And the other problem is that if you are just tossing blobs of data in your application's native representation into the DB, it doesn't give you a chance to access it from other languages or platforms when you want to make evolutionary changes or add different components. > 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. I'd think java would do a better job of charting. Have you looked at the Pentaho tool set? Their site is site is somewhat confusing about what is commercial and what is free, but look for the 'community edition'. Among other things there is a GUI report writing tool to do the layout you want with data from an assortment of sources. Then there is the 'bi-server' that will render the report as a web service with html/pdf/excel/csv/test output - and you can schedule them to be run at pre-set times into a cache or email. Jasper reports and BIRT have similar capabilities. > 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. Look at what RHEL 6 has. I think you can still download their beta - or Scientific Linux has their alpha release out (SL is very similar to Centos, rebuilding from the same source but they add a few things). http://distrowatch.com/?newsid=06401 -- Les Mikesell lesmikesell at gmail.com