Hi guys,
I've been using the code in trunk in the last 6 months and I didn't spot
any relevant issues with it. I would like to write down a few ideas for
releasing it as rivet-3.0.0 in 3 or 4 months. What is missing to rivet 3.0?
- A 3.0 branch should be created in order to separate code additions
that could bring instability in the code. Yes, I know, I'm a paranoid,
there is no 'svn commit' storm taking place on our repository :-(
- Basically the test suite should be able to run with different MPM
and different MPM bridges (not every pair of MPM module and bridge are
possible though). Furthermore some tests are just meant to avoid
regression with commands and in principle should be bridge and MPM
independent. Anyway I will try to make the test suite run in a sort of
'for' loop for each meaningful MPM and bridge pairing
further developments to be done in 'trunk' (hence separated by the 3.0
branch)
- I'm considering to place into the repository the framework I've been
working on for quite a few years. I was afraid to propose it and it
probably needs more work, but if I don't throw it into the repository it
will have no chance to grow. Taking inspiration from a motto quoted on
@members recently the philosophy of the framework is 'less is more (at
least sometimes)'. I mean the idea of the framework was to have a very
simple pattern of collaborating components on which you may develop more
elaborate application features. The code was and it's still written
using Itcl but moving to TclOO should be straightforward. Furthermore
you need it if you want to reproduce tcl.apache.org and
tcl.apache.org/rivet/
- The framework needs a few configuration scripts to be set up
consistently. I'm wondering if we could imagine a way to create some
sort of scripted configuration, something that should enable the
programmer to set up a single configuration directive with a tcl script
that should fetch the basic environmental data and prepare the final
configuration (or blend into it somehow). An alarm bell keeps ringing in
my ears, does it open the way to subtle security holes? I can't figure
out a way to rule it out but also I can't image how this could less
secure of the current way to set up mod_rivet environments
sorry for the lengthy message.
-- Massimo
--
Dipartimento di Neuroscienze
Unità Biofisica e Fisica Sanitaria
via Volturno 39
43125 Parma
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org
For additional commands, e-mail: rivet-dev-h...@tcl.apache.org
