You are viewing a plain text version of this content. The canonical link for it is here.
Posted to rivet-dev@tcl.apache.org by Massimo Manghi <ma...@unipr.it> on 2012/12/19 14:59:27 UTC
reforming Rivet Tcl packages
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
* Providing support for dictionaries and letting arrays be just a
special case would plainly extending DIO without creating incompatibilities
* I propose to rename the package as AIDA: Agnostic Interface to
Database Access
- 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
- 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)
- Various
* Anyone has any experience/interest with NoSql databases?
-- Massimo
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: reforming Rivet Tcl packages
Posted by Massimo Manghi <mx...@apache.org>.
On 12/19/2012 03:13 PM, Harald Oehlmann wrote:
> Am 19.12.2012 14:59, schrieb Massimo Manghi:
>> 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.
>
> Very good ideas. I already use tdbc and mysql with rivet due to that reason.
>
> I propose to migrate package "form" from incrtcl to tclOO.
> Even if incrtcl is now a core bundled package I would prefer tclOO.
>
oh yes, I regret I decided to stick to Tcl 8.5. Working on this project
I suddenly realized I needed mixins to make my design much more flexible.
-- Massimo
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: reforming Rivet Tcl packages
Posted by Harald Oehlmann <ha...@elmicron.de>.
Am 19.12.2012 14:59, schrieb Massimo Manghi:
> 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.
Very good ideas. I already use tdbc and mysql with rivet due to that reason.
I propose to migrate package "form" from incrtcl to tclOO.
Even if incrtcl is now a core bundled package I would prefer tclOO.
Enjoy,
Harald
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: reforming Rivet Tcl packages
Posted by Massimo Manghi <mx...@apache.org>.
On 12/19/2012 04:25 PM, Karl Lehenbauer wrote:
>
>>
>> * 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.
>
I've been using it in the last month to do a project. It didn't required
intensive and demanding DBMS interaction, just managing a relatively
small dataset. I would be happy to keep this code compatible with future
releases of Rivet. I don't use some rather special feature of DIO such
as autokeys (which I failed to understand initially and never got
bothered trying to understand them later on). So I'm confident I could
wrap TDBC around the basic DIO interface to provide at least a partial
compatibility layer for the basic calls.
> 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.
I don't see why we couldn't use TDBC
>>
>> - 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.
>
Does your custom session code bear some suggestions for reworking and
improving Rivet's own Session package?
>> - 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.
>
Oh no I agree about the problem with certain data structure
representation...but dicts have been out there for quite several years
and we have calls to DIO that return results as lists or arrays or
strings....why not dicts that can be passed around as values?
::rivet::inspect is an example as the configuration database can be
comprehensively be represented like a tree rather than simply a flat
array (having Server, Dir and User sections).
As an expoeriment recently I tried to develop a prototype of framework
using just dicts as object instance representations and namespace
ensembles as object manipulators/interfaces. It was like an exercise I
gave myself. It worked quite well at first until I tried to combine
object instances into containers like lists. The problems became rapidly
harder and harder and decided to give up
> 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.
>
I think this guy meant to be provocative and its statement went
uncommented by the audience. It was in the thread you started about
clearing Tcl from unused/obsolete constructs and features.
>> - 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.
>
thanks for the suggestion, very interesting.
-- Massimo
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: reforming Rivet Tcl packages
Posted by Karl Lehenbauer <ka...@gmail.com>.
On Dec 19, 2012, at 7:59 AM, Massimo Manghi <ma...@unipr.it> 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: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org