The Func API should be altogether, for ease of use and documentation. (They are in develop.)
Without giving ANY statement of agreeing or disagreeing with the request itself I change the priority to normal because this cannot in any way be a release blocker for 4.0.3.
This bug reports maybe deserves to be given attention for a while in Codev? Which extentions of the API are needed? And wanted? And when (which release?).
In fact, it shouldn't be in 4.0 at all. If I checked those boxes, I made a mistake. (And have unchecked the 4.0 boxes). It might be helpful to add a 4.1 checkbox for things that people think should go into it. ~develop is far too vague.
we forgot, maybe for 4.1.1?
Yep, this is desperately required. I was trying to avoid doing it, but....
I will have no code refactorings like this in now. I have a few hours Friday and Saturday and Sunday I release. So this is earliest 4.1.2
And with the rate bugs come in that may be in only a month or two so no need to panic.
Darn. This is really important, it would be great if it could go in. It's not a refactoring, it entirely new functionality moving from a Contrib into the core, with minimal impact on existing code. All the tests pass, which is more than can be said for some other code. It finally completes user mapping managers, and provide the long-awaited ACLs API.
BTW the work is complete; if you still don't want it in, please flip back to Waiting for Release.
I will not integrate it in 4.1.1. Simply because of risk. And only because of risk of injecting new bugs. I simply do not have time enough to test it. But it is OK for a patch release as long as it is 4.1.2. So I will keep it in Waiting for feedback from me. And the minute 4.1.1 is released (less than 48 hours from now) I will merge it into Patch04x01 so it becomes part of 4.1.2 which we know we will release maybe 30 days after (Perl 5.6 support will drive that release)
CDot, are you aware that asking for all
users is a bad thing(tm) and may
very likely take down your TWiki with even a medium size userbase?
You should never ask for so much information in one chunk,
then store it, then process it. If you ever need to process a potentially
large set then do so while iterating over it. Don't copy it first.
Yes, I'm well aware of that. However that API was part of the contrib, so I merged it across.
After some discussions with Micha last night, I'm withdrawing the proposal to merge this and dropping it back to "Being Worked On". The issue really is how far we go in refactoring this. It's obvious that we shouldn't expose user objects via the Func API, but there is a question whether we should remove them from the internal APIs as well. Also, as Micha pointed out, all users methods are bad news on large sites. We need to provide iterators rather than list methods.
OK, I decided to simplify the merge significantly, and only cherry-picked the most obviously essential functions. See TWiki::Func for all functions marked "Since 1.12"
The big question is; 4.1.2, or wait for 4.2? These are all API additions
, so should not affect existing users. I could really do with some reviews.
I have no strong oppinions against entry to 4.1.2. But I would like to hear others oppinions.
Are there plugin authors that really want this in 4.1.2?
Please see TWiki:Codev/MergeFuncUsersContribWithFunc
for new API details.
yes, there are a number of my plugins that rely on Func APIs that we developed this way - and quite a few customers (including ones that sponsored Plugin development).
After having seen how many code lines this is then the answer NO. We are not doing such major code refactorings in a Patch release. Then the right thing to do is to schedule a 4.2 in a not so distant future.
I do not want to see new bugs injected into the 4.1 branch. Only bugfixes. The well tested kind.
IMHO, the user objects and is use is quite overkill. Most methods in
delegate the call to the real implementation via
pointer. The real implementation then only calls back the user object to get the login name (or the wiki name). So creating
user objects just to please this api is pointless. You could pass the login name to the real impl in
or the password manager or the
user mapping right away. Without first storing it in a user object.
This is done.