• Do not register here on develop.twiki.org, login with your twiki.org account.
• Use View topic Item7848 for generic doc work for TWiki-6.1.1. Use View topic Item7851 for doc work on extensions that are not part of a release. More... Close
• Anything you create or change in standard webs (Main, TWiki, Sandbox etc) will be automatically reverted on every SVN update.
Does this site look broken?. Use the LitterTray web for test cases.
The Func API should be altogether, for ease of use and documentation. (They are in develop.)

ML

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

KJL

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.

ML

damn frown we forgot, maybe for 4.1.1?

SD

Yep, this is desperately required. I was trying to avoid doing it, but....

CC

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.

Kenneth

KJL

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.

CC

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)

KJL

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.

MD

Yes, I'm well aware of that. However that API was part of the contrib, so I merged it across.

CC

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.

CC

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.

CC

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?

KJL

Please see TWiki:Codev/MergeFuncUsersContribWithFunc for new API details.

CC

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

SD

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.

KJL

IMHO, the user objects and is use is quite overkill. Most methods in User.pm delegate the call to the real implementation via Users.pm passing over the $this 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 Users.pm or the password manager or the user mapping right away. Without first storing it in a user object.

MD

This is done.

CC

ItemTemplate
Summary FuncUsersContrib and MoreFuncContrib and FuncusersContrib should be merged into Func
ReportedBy TWiki:Main.MeredithLesly
Codebase ~twiki4
SVN Range Wed, 24 May 2006 build 10305
AppliesTo Engine
Component

Priority Normal
CurrentState Closed
WaitingFor

Checkins 12719 12720 12792 12799 12800 12810 12894
TargetRelease minor
ReleasedIn 4.2.0
Edit | Attach | Watch | Print version | History: r29 < r28 < r27 < r26 < r25 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r29 - 2008-01-22 - KennethLavrsen
 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback