Re: branch 1_0 development status
Lets leave everything as it is - i mean tags and branches. Right. Apache2 module is still unusable - when we'll be able to finish it is unclear. Because as far as i see, we have to agree with set of features and design of rivet first. That's easy: Apache 2 should do what Apache 1 does in terms of handling .rvt and .tcl files. After that, then other things can be added. Well, realistically, since he who does the work decides, if you really want to add something that everyone agrees is cool, then that's what you get to do. But if you need a plan, the plan is to make Rivet work with Apache 2. Part of that unfortunately means taking a good look at the code already there, because I don't think it correctly uses the Apache API's. Once this is done, we'll have to concentrate on development... Looks like long way to go for me. My proposal is: 1.Leave 1_0 branch as it is, and do all development in the trunk. 2. Discuss the layout of rivet and our aims, get the plan of tasks that needs to be done, preferably with precise description of what and how needs to be done. This will allow to new people to jump in and start doing somethingl immediately, also this will allow us to work on those tasks separately, still having understanding of who and what trying to achieve. As far as I can tell, it's just you and Massimo, so I don't think too much planning is necessary - just a bit of coordination so that you're not working on the same file at the same time. -- David N. Welton http://www.welton.it/davidw/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: branch 1_0 development status
Hello, guys ! I agree with most of your arguments. During this week (may be the next one), i'll try to sum up all my thoughts on apache2 module, and will post my detailed vision to [EMAIL PROTECTED] That will be good starting point. Regards, Valery. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: branch 1_0 development status
Hello, Massimo ! Lets leave everything as it is - i mean tags and branches. Apache2 module is still unusable - when we'll be able to finish it is unclear. Because as far as i see, we have to agree with set of features and design of rivet first. Once this is done, we'll have to concentrate on development... Looks like long way to go for me. My proposal is: 1.Leave 1_0 branch as it is, and do all development in the trunk. 2. Discuss the layout of rivet and our aims, get the plan of tasks that needs to be done, preferably with precise description of what and how needs to be done. This will allow to new people to jump in and start doing somethingl immediately, also this will allow us to work on those tasks separately, still having understanding of who and what trying to achieve. Regards Valery. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: branch 1_0 development status
David Welton wrote: The package name is 'Rivet'. It looks to me an arguable choice unless the authors had in mind some sort of major reorganization of the rivet commands. 'Rivet' (the package) provides 2 other (undocumented ?) sets of commands: a simple cryptographic system (a data obfuscation method ?) and a set of improved list objects manipulation methods inspired by Tclx. I don't even know if the code for these module is tested. As far as I'm concerned, you can change the name. If anyone squawks, we'll know that they didn't like it. But they should probably be on this list in any case... Rivetlib! At one point in time, my idea was a minimalistic core, with lots of readily available extensions. I don't think that's the wisest course of action these days. Who cares about saving a few bytes. yes, I agree My opinion is that coming up with a 1_0 release that compiles only for apache1.x is not a option anymore. I think that's a sensible point of view. It would look a little bit ridiculous. Let's call it 2.0 :-) you've been selling used cars lately! :-) Rivet0.6 for apache1, Rivet2 for apache2, Rivet2 for apache1:- what an headache! It sounds ridiculous but I thought of the same thing. After all it makes life easier to whom have to pick the right version of the module...let put it in this way -- Massimo -- M - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
branch 1_0 development status
Hi Folks
I've been working a bit on what seemed to me a bug at first
(we discussed on the list this problem about one year ago).
Some of the documented commands of rivet ('[un]escape_string'
and others) where not available to the interpreter.
A close look at the code shows that librivet.so (which has
the functions for these commands) was not meant to be a
shared library linked to mod_rivet.so but a full fledged
Tcl package that can be yanked in by tcl scripts with the
usual 'package require' command.
The package name is 'Rivet'. It looks to me an arguable choice
unless the authors had in mind some sort of major reorganization
of the rivet commands. 'Rivet' (the package) provides 2 other
(undocumented ?) sets of commands: a simple cryptographic
system (a data obfuscation method ?) and a set of improved
list objects manipulation methods inspired by Tclx.
I don't even know if the code for these module is tested.
To say the least a minimal documentation for these commands
is needed and the current documentation should be updated
for those commands that need a 'package require Rivet' in order
to be available. I can do it, but I was wondering what the
authors had in mind: continuing the pursuit of their goals
would probably be a good option and could be part of the work
we are doing
My opinion is that coming up with a 1_0 release that
compiles only for apache1.x is not a option anymore.
Apache2 has been out for too long now and we have to
continue the development. Nonetheless having a 1_0
with complete documentation, a good code structure
and build system could help the work in trunk.
looking forward to read your opinion
regards
-- Massimo
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
