On Dec 19, 2012, at 7:59 AM, Massimo Manghi <[email protected]> wrote:
> in the wake of what's going on on Tclcore I would like to start a thread on > the future of Rivet. I've worked recently on a project involving Rivet and > definitely everything is too deeply rooted in the pre-8.5 era to be 'modern' > Tcl. > > just a few ideas > > - DIO package > > * It should probably be rewritten around the TDBC package. This would > simplify its future maintenance and it would hand on to TDBC the support for > the dependencies it has now on various DBMS connectors. > Most Tcl programmers would probably prefer TDBC for any new application Does anybody still use DIO? I think that it is overall pretty good stuff except there is too much computational overhead in its implementation. FlightAware uses FA-wrapped, native Pgtcl interfaces to PostgreSQL's C library, libpq. pg_select in particular gets a thorough workout. I haven't reviewed or used TDBC, but I am happy with Pgtcl's tclishness (pg_select works a lot like foreach, for instance, and obviates mucking around with result handles), its deep access to PostgreSQL client/server capabilities such as asynchronous requests, partial results, etc, which probably don't have a meta analogue, and the powerful but little known sc_postgres package in Pgtcl that generates and performs SQL inserts and updates from arrays and lists, converts between epoch times and SQL dates and times, etc. I mention this mostly to point to that native interfaces will almost always integrate more deeply than a generalized wrapper and that FA is unlikely to move away from this, other than perhaps for a wee bit of mysql that is forced on us. > * I propose to rename the package as AIDA: Agnostic Interface to Database > Access Is it possible to just use TDBC or does there need to be an additional layer or what. > > - Session package > > * Rewrite it and make it TclOO and TDBC based. There are several cases where > you would like sessions to interact with the application code in a flexible > way. Mixins would come handy in these cases avoiding the all too rigid > subclassing Fine with me. Although I consider the session package stable and useful, we (FlightAware) have our own fairly intense custom session stuff, so I certainly haven't given it a heavy workout. > - Core > > * Review commands interacting with arrays and consider to support > dictionaries wherever possible (on tclcore someone even put forward the idea > of dropping arrays support in Tcl9) I am not a big fan of dicts. I think they fail to solve Tcl's data representation shortcomings in a convincing, smoothly-integral-to-the-language manner, and there are what seems to me fairly simple data structures that are either unrepresentable in dicts or require kludging. Not sure you agree? Try comparing accessing / manipulating / walking the DOM in Javascript versus doing it in Tcl. Getting rid of arrays in Tcl 9 would be insane (I better get caught up on my core list email) and surely it's been treated as a laugh or a nonstarter. > - Various > > * Anyone has any experience/interest with NoSql databases? We make heavy use of speedtables. This powerful open source technology (available on github) is possibly the fastest single machine NOSQL-type database in existence. It can be used locally and privately, client/server over TCP, or via a combination of TCP and shared memory. If you're interested in adding some kind of NoSql support to Rivet I invite you to investigate it as it has been revolution for us. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
