Brian Lloyd writes:
There seems to be danger that this great support through a community member will have a fate similar to Tino's "in" patch:
that the incorporation into the Zope core is far too long delayed because important DC people fear "feature bloat".
It is not "feature bloat" in this case that is the main issue, it is (as stated in my comments in the proposal) the complexity this adds. But the added complexity is really small: about 10 to 15 lines of description:
Instead of "sort=col,col,col,..." you now have "sort=colsort,colsort,colsort,..." with "colsort" either * col * col/compare * col/compare/direction
Please understand that we are sometimes put in a difficult position - we get beaten up all the time about "zope being too complex", then get beaten up by other folks when we question a feature because we don't want to add to the complexity :) I think, I have addressed this in a proposal comment:
* high level sort support adds (a bit of) complexity * if you need advanced sorting (and already case-insensitve sort is currently advanced!) then, without high level sort support, you need a very complex solution (in Python). * many Zope users need better sort support - e.g. case insensitive sort (--> mailing list archives), locale aware sorts (--> users in South America, Europe, Asia). They either are/get advanced Python programmers or feel that Zope is far too complex, because simple things are not easy to get. Accepting the patch will not increase but decrease the complexity for all people that need better sort support. I think this is the majority.
....
DM: In my view
* bug fixing patches should always be accepted unless the patch is not easily understandable.
* feature patches should be accepted, if it makes Zope more consistent (as the upcoming "urlparam_expr" patch) or easier to use (as Oleg's sorting patch or Tino's in patch).
Great reluctance towards these contributions risks Zope to lose community support. BL: I agree with the first point, and it is generally true though there is often currently too much lag time. There will be good news forthcoming that will help that significantly soon.
The second point is subjective - what is "more consistent" to one is sometimes "more inscrutible" to others. Yes, sometimes. But often, it should be easy to come to an agreement.
For example: Zope DTML attributes often come in two variants: "branches/branches_expr", "type/type_expr", "sort/sort_expr",.... It has a reason that this is so... Sometimes, only a single attribute is there. This can have two reasons: the second one is not needed or it was forgotten or not implemented due to resource shortage at the time of implementation. Now, people stumble against that lack (me, for example against the missing "urlparam_expr"). They may say, hay, I could help to make Zope better (I did not, in this case, but used a cookie - with a comment about the badly designed "urlparam" in the source of my code) and file a patch into the Collector. It should not be difficult to see that Zope gets more consistent with such a patch. I think, it should be easy, too, for Oleg's patch: The usefulness/complexity ratio is extremely good. Nevertheless, I expected it would make problems and adviced him to make his features alvailable in an easy to use external method such that the Zope community is less dependent on DC in this respect.
BL: The whole point of the Fishbowl is to help us all come to smart decisions and reasonable compromises on such things. In my view, the Fishbowl should be used only for big things.
I can understand, that projects like Tino's patch or "Administration and Configuration" go through the Fishbowl. Everything, that has either big impact or requires extensive resources with DC. I would be seriously concerned, if there would be an "urlparam_expr" project in the Fishbowl before this patch could be accepted. I would also not have expected a Fishbowl project for Oleg's patch. The patch is local, finished. Everything DC needs to do is apply it (I know, this is already done in CVS) and add a dozen lines in the Online Help and the Zope book. The resource consumption with the Fishbowl project is one to two orders of magnitude larger than this.
DM: I still advice people to file bug reports and patches into the Collector, but personnaly I already start to think whether it is worth the effort....
BL: It is worth the effort. .... resource shortage to sweep the Collector ....
That will be changing. Good!
I will be (a bit) patient.
....
Dieter