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: rivet-dev-unsubscribetcl.apache.org
For additional commands, e-mail: rivet-dev-helptcl.apache.org

> 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.

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...

> 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

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.

> 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 

> 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.

-- 
David N. Welton
http://www.welton.it/dav
idw/

------------------------------------------------------------
---------
To unsubscribe, e-mail: rivet-dev-unsubscribetcl.apache.org
For additional commands, e-mail: rivet-dev-helptcl.apache.org

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: rivet-dev-unsubscribetcl.apache.org
For additional commands, e-mail: rivet-dev-helptcl.apache.org

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: rivet-dev-unsubscribetcl.apache.org
For additional commands, e-mail: rivet-dev-helptcl.apache.org

> 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/dav
idw/

------------------------------------------------------------
---------
To unsubscribe, e-mail: rivet-dev-unsubscribetcl.apache.org
For additional commands, e-mail: rivet-dev-helptcl.apache.org

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 rivet-dev. That
will be good
starting point.

Regards, Valery.

------------------------------------------------------------
---------
To unsubscribe, e-mail: rivet-dev-unsubscribetcl.apache.org
For additional commands, e-mail: rivet-dev-helptcl.apache.org