Re: [AOLSERVER] TclX keyed list changes in HEAD

2004-06-22 Thread Zoran Vasiljevic
On Tuesday 22 June 2004 18:24, you wrote:
 Zoran implemented some recent changes to TclX keyed lists in CVS HEAD
 which changed the C API, which broke at least some code at AOL which was
 still using the old C API.

Ah, the C-API you're talking about! Well, this is right.
This has changed. I see no problem in addint the compat
layer on top of that.

Zoran


--
AOLserver - http://www.aolserver.com/

To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the
body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of 
your email blank.


Re: [AOLSERVER] TclX keyed list changes in HEAD

2004-06-22 Thread Zoran Vasiljevic
On Tuesday 22 June 2004 18:24, you wrote:
 Zoran implemented some recent changes to TclX keyed lists in CVS HEAD
 which changed the C API, which broke at least some code at AOL which was
 still using the old C API.


???
There are no Tcl-level changes to keyed list commands.

 Rather than a wholesale back-out of the changes, I'd like to discuss two
 things:

 1) Should changes that break backwards compatibility be allowed between
minor revisions (i.e., 4.0 - 4.1) or should they be limited to major
releases only (i.e., 4.x - 5.x).

Simple. They are not allowed. It has to be backward compatible.
But, what are the changes between string and object-based
keyed-list commands? Can you please be more descriptive?


 2) Can we quickly implement some backwards compatibility for the TclX
keyed list C API so that existing C code won't need to be
modified/updated to use Zoran's new C API?  What's the best way to do
this?  Can it be done through #define's?  Or thin wrapper C procs
that call the new C procs?  Or, can we simply rename Zoran's new C
procs to the old names to preserve compatibility?

Again, I see no problems to make any backward-compat changes.
I would like to see the problems first.
The TclX keyed-list commands are those found in TclX package already.

Zoran


--
AOLserver - http://www.aolserver.com/

To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the
body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of 
your email blank.


Re: [AOLSERVER] TclX keyed list changes in HEAD

2004-06-22 Thread Brett Schwarz
Zoran,

I am just curious what you have done. Did you update
the AS code to match what is at tclx.sf.net? Or is
this just something you did? I believe you converted
to the Tcl objects, but wasn't sure if you took it
from SF or did it on your own.

thanks,

--brett

--- Zoran Vasiljevic [EMAIL PROTECTED] wrote:
 On Tuesday 22 June 2004 18:24, you wrote:
  Zoran implemented some recent changes to TclX
 keyed lists in CVS HEAD
  which changed the C API, which broke at least some
 code at AOL which was
  still using the old C API.

 Ah, the C-API you're talking about! Well, this is
 right.
 This has changed. I see no problem in addint the
 compat
 layer on top of that.

 Zoran


 --
 AOLserver - http://www.aolserver.com/

 To Remove yourself from this list, simply send an
 email to [EMAIL PROTECTED] with the
 body of SIGNOFF AOLSERVER in the email message.
 You can leave the Subject: field of your email
 blank.



--
AOLserver - http://www.aolserver.com/

To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the
body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of 
your email blank.


Re: [AOLSERVER] TclX keyed list changes in HEAD

2004-06-22 Thread Zoran Vasiljevic
On Tuesday 22 June 2004 18:33, you wrote:
 On Tuesday 22 June 2004 18:24, you wrote:
  Zoran implemented some recent changes to TclX keyed lists in CVS HEAD
  which changed the C API, which broke at least some code at AOL which was
  still using the old C API.

 Ah, the C-API you're talking about! Well, this is right.
 This has changed. I see no problem in addint the compat
 layer on top of that.

The new TclX commands expored are:

 TclX_KeylgetObjCmd
 TclX_KeylsetObjCmd
 TclX_KeyldelObjCmd
 TclX_KeylkeysObjCmd

Equivalents of those are found in older string-based api.
There is no problem in quick simple compat layer for those.
The old string-based api allows additionaly for:

 Tcl_DeleteKeyedListField
 Tcl_SetKeyedListField
 Tcl_GetKeyedListField
 Tcl_GetKeyedListKeys

Do you need those abstraced as well?

Sorry for breaking the compat, I should have asked first
if anybody uses the C-API before applying the change and
should have written the compat layer as well at the same
time.

Zoran


--
AOLserver - http://www.aolserver.com/

To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the
body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of 
your email blank.


Re: [AOLSERVER] TclX keyed list changes in HEAD

2004-06-22 Thread Zoran Vasiljevic
On Tuesday 22 June 2004 18:48, you wrote:
 Zoran,

 I am just curious what you have done. Did you update
 the AS code to match what is at tclx.sf.net? Or is
 this just something you did? I believe you converted
 to the Tcl objects, but wasn't sure if you took it
 from SF or did it on your own.

It is the code from TclX package. I just made it work
for AS.

Zoran


--
AOLserver - http://www.aolserver.com/

To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the
body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of 
your email blank.


Re: [AOLSERVER] TclX keyed list changes in HEAD

2004-06-22 Thread Jim Wilcoxson
Hi - here are my thoughts on compatibility:

Breaking compatibility at the TCL level is worse than breaking it at
the C level.  If someone wants to write a new, incompatible version of
ns_return for example, it should be called something else and a
compatibility wrapper written for ns_return that calls the new thing.
In the best case, TCL compatibility should NEVER be broken.  If we
end up with a huge compatbility library, perhaps all written in TCL,
that's much preferable to telling people to change their code.

Breaking compatibility at the C level is more acceptable to me, because
my guess is that very few people are using it.  We have a small handful
of C modules, so yeah, we may have to change them if the C API changes,
but it would not be a big deal.

Even if incompatible changes are allowed at major versions, what may
very well happen is that it fractures the community and leaves some
people running old versions longer than they want.  We're in this
situation now because of ns_shares: someone decided it was
inconvenient to provide ns_share because of TCL core modifications,
which I totally understand.  But, we have a code base with over 800
ns_share statements, and probably 5x that many variable references.
It will be a cold day in Hell before we rewrite all our code to use
nsv arrays, just because someone decided that ns_shares are
inconvenient to support.  If ns_share ever goes away completely, we
won't be upgrading, no matter how great a new version is.

The other paradox with good, reliable software is that people don't
have as much of a pressing need to upgrade it.  So while a development
group is releasing version after version of a product, and may have
even released several production versions, there will be many
customers that have not even tried the new version.  Eventually, there
will be a pressing need that forces the customer to consider
upgrading.  The Linux OS is an example of this, for us.  We didn't
upgrade to 2.4 until November of 2003, even though 2.4 had been
released for a long time, because 2.2 was working fine for our needs.
The 2 things that forced us to upgrade were that we needed to access
more main memory, and our storage requirements increased to the point
that we couldn't afford to do fsck's and needed a journaling file
system.  My point is, production customers may be running old versions
much longer than developers think.  If a customer has been happily
running 3.4 AS for a few years and a compelling reason comes along for
them to upgrade, and the current version of AS is 6.5, they don't want
to run into a big incompatibility hurdle.  If they run into too big of
a hurdle, they will likely start considering all options, including
moving to a different platform that they perceive is more stable from
a compatibility point of view.

Jim


 Zoran implemented some recent changes to TclX keyed lists in CVS HEAD
 which changed the C API, which broke at least some code at AOL which was
 still using the old C API.

 Rather than a wholesale back-out of the changes, I'd like to discuss two
 things:

 1) Should changes that break backwards compatibility be allowed between
minor revisions (i.e., 4.0 - 4.1) or should they be limited to major
releases only (i.e., 4.x - 5.x).

 2) Can we quickly implement some backwards compatibility for the TclX
keyed list C API so that existing C code won't need to be
modified/updated to use Zoran's new C API?  What's the best way to do
this?  Can it be done through #define's?  Or thin wrapper C procs
that call the new C procs?  Or, can we simply rename Zoran's new C
procs to the old names to preserve compatibility?

 -- Dossy

 --
 Dossy Shiobara   mail: [EMAIL PROTECTED]
 Panoptic Computer Network web: http://www.panoptic.com/
   He realized the fastest way to change is to laugh at your own
 folly -- then you can let go and quickly move on. (p. 70)


 --
 AOLserver - http://www.aolserver.com/

 To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with 
 the
 body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field 
 of your email blank.



--
AOLserver - http://www.aolserver.com/

To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the
body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of 
your email blank.


Re: [AOLSERVER] TclX keyed list changes in HEAD

2004-06-22 Thread Zoran Vasiljevic
On Tuesday 22 June 2004 18:24, you wrote:
 Zoran implemented some recent changes to TclX keyed lists in CVS HEAD
 which changed the C API, which broke at least some code at AOL which was
 still using the old C API.

 Rather than a wholesale back-out of the changes, I'd like to discuss two

A wholesale back-out of the changes seems like a very desperate step, hm?
Since the CVS head is the development branch, changes to it should be
allowed. Or not? Besides, head should not be used for any productive
environment, AFAIK. If the checkin policy on head should be that rigorous,
then we'll advance very, very slowly, which is bad, isn't it?

As far as this particular issue is concerned, I did this purely for the
benefit of other folks. Somebody has to take care, ok?

Anyways, the compatibilty layer for following old calls has been done:

  Tcl_GetKeyedListKeys
  Tcl_GetKeyedListField
  Tcl_SetKeyedListField
  Tcl_DeleteKeyedListField

I *did not* wrap the:
  Tcl_KeylgetCmd
  Tcl_KeyldelCmd
  Tcl_KeylkeysCmd
  Tcl_KeylsetCmd

since those are only Tcl-API interfaces. I doubt that anybody
would seriously use them. If I'm mistaken, please tell me and
I will add those as well...
Now, checkout the head and recompile. If there are *any* problems,
please feel free to contact me directly ([EMAIL PROTECTED]) so we
do not saturate the list. I do not think this is the right place
to discuss such issues. For that, there is SF bug tracker.

Zoran


--
AOLserver - http://www.aolserver.com/

To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the
body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of 
your email blank.


Re: [AOLSERVER] TclX keyed list changes in HEAD

2004-06-22 Thread Andrew Piskorski
On Tue, Jun 22, 2004 at 10:04:14AM -0700, Jim Wilcoxson wrote:

 Even if incompatible changes are allowed at major versions, what may
 very well happen is that it fractures the community and leaves some
 people running old versions longer than they want.  We're in this

This has happened extensively with AOLserver in the past, but I think
primarily NOT because of broken backwards compatibility, but because
there was no attempt at all, sometimes for years at a time, to
integrate fixes and patches into the master CVS sources in anything
even resembling a timely and reliable fashion.  Fortunately, that
situation seems to have much improved already, and hopefully will
continue to do so.

 If a customer has been happily running 3.4 AS for a few years and a
 compelling reason comes along for them to upgrade, and the current
 version of AS is 6.5, they don't want to run into a big
 incompatibility hurdle.  If they run into too big of

Frankly, there isn't much the AOLserver developers - or ANY external
developers - can do about that.

As a customer, part of the operatins and maintenance cost of ANY piece
of software is upgrading every year or so to the latest and greatest
version.  If you ignore that maintenance for, say, 5 years running,
when you finally do decide to upgrade, no surprise, you are going to
have a LOT more work to do, all at once, then if you'd tracked
development more closely upgrading a year at time.  You'll also have
completely abdicated any feedback or input into the software for those
5 years of development, which may further increase your upgrade
effort.

Make no mistake, CHOOSING to ignore newer versions of software because
what we're using now is good enough (and I myself have sometimes
done so) is a serious operations decision, with both rewards AND
risks.  And it is fundamentally the customer's responsibility to
properly evaluate that decision - no external group of developers can
do it for you, nor should they.

What developers CAN do, is communicate as clearly, frequently, and
consistently as possible where they're currently planning to take the
code, when, and why, and be as receptive as possible to fixes and
modifications that come from the larger user community.

So e.g., ideally, if the AOLserver team finally drive stake through
the heart of whatever deprecated legacy support still exists in the
core for ns_share say for AOLsrever 5.0, or for 4.2, they'd let you
know that well ahead of time, consider ways to provide an ns_share
backwards compatibility module and help the (probably very small
minority of) users who want that to maintain it, etc.

--
Andrew Piskorski [EMAIL PROTECTED]
http://www.piskorski.com/


--
AOLserver - http://www.aolserver.com/

To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the
body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of 
your email blank.