Pony99CA wrote:First, it doesn't matter if this is an Auto Groups RFC or not. It's for proposing methods for preventing users from posting links. Your proposal does this, my proposal does this. Mine is just more extensible and supports many other possibilities beyond posting links.
First, it does matter since we don't even know if auto groups is going to be in the core. My proposal works without it, with a simple field added to the group wide settings. Let's not torpedo my idea by requiring another piece (AG) that may *not* get approved in order for my idea to work.
Auto Groups could be implemented as part of
this RFC, not as a dependency. That's a call for the developers to make. RFCs generally present a functional view of how things will work, not a development spec. So, in that respect, it doesn't matter.
Pony99CA wrote:Second, both methods allow specifying post counts for things. Yours is more explicit about what the post count controls, mine controls what groups the user is in based on post count and uses the phpBB permission system to decide what people in that group can do or not do. The problem with yours is that every time somebody wants a new post-count-based permission, the developers have to add it to the core or somebody has to write an extension to support it. With Auto Groups, once that's written, you're done!
Second, yes, and with AG you also have to swap people in and out of groups which could get pretty extensive and expensive.
That's why I don't like the term "swap" here (or at least the way that you use it). You
(the Admin) don't have to swap people in and out of groups. You set the post counts for group membership and the code
determines which group the user is in.
Also, any swapping is only done when the user hits a post count limit (although every post will require those limits to be checked, of course, even if no swapping is done).
But that already happens today with the Newly Registered Users group. In fact, the NRU group is really just a kludgy subset of Auto Groups. I wish the developers had implemented Auto Groups back then as a way of implementing the NRU group, which would have also given us the capability to do exactly what I'm asking for. If they had generalized the solution back then, you may not have even needed to start this RFC....
Master_Cylinder wrote: Pony99CA wrote:
Third, I agree that times, sizes, character coutns, etc. wouldn't work for Auto Groups, and are better suited for Group wide settings
, but that's because they aren't really meant to be dynamic. Things like post counts and days since joining the board would be perfect for Auto Groups. And, with Auto Groups, getting "promoted" to a new group based on a good criterion could allow posts with more characters or more PMs in a folder.
(But, again, I'm not promoting Auto Groups for the sake of having them; I think they allow for a much more flexible and and extensible solution to this
problem than your proposal does.)
Third, while this is post count related, there is still no need to swap people in and out of a group to achieve it. The lighter solution should be used for this anti-spam issue.
We disagree. As I said, it's a developer's call whether Auto Groups would be too heavy.
If you don't want more load, though, you should probably stick to phpBB 3.0; phpBB 3.1 is already adding lots of load from the posts that I've seen.
Pony99CA wrote:Finally, you have a fair point about load -- while the user doesn't have to swap people in and out of groups, the system has to check which groups a user belongs based on post count, which could create more load. That's a question for the developers.
Finally, load is *not* a small issue with using AG[....]
I didn't say that it was a "small issue", so why the emphasis? Did you benchmark a solution with and without Auto Groups and you're using the emphasis to show that Auto Groups is very expensive? If you have, let's see the numbers; otherwise please don't make that claim.
Master_Cylinder wrote: Pony99CA wrote:
It's perfect for handling standard phpBB permisson-based options (Yes/No/Never), though. One size truly does it all here.
Not everything is solved with yes/no/never and, as above, we don't even need those for this to work.
Not for your
suggestion to work. We do need it for mine.
And what happens when somebody wants to make an existing
permission (like Can use Flash
) based on post-count? Then you'd have two places for that permission. I suppose that you could set the permission to Yes and then the Group Wide Setting to the post count, but that's not very elegant.
Pony99CA wrote:Let's not use "swapping", which sounds like the Admin has to do it (which he doesn't -- that's the point of Auto Groups). Determining which groups the user is in is done at run-time more in my proposal, hence my agreeing that load might be an issue.
Swapping is accurate since members are moved in and out of groups based on post counts. That it's done by cron or during checks at post time/login time just adds to the load and, again, that's why it's not good for every option. Why a group for this? So they can have different ranks and avatars for x posts? C'mon, a group for this is a waste.
I could argue that a Group Wide Setting is a waste in many cases. If we had a Can use links
permission, that could be set to Never for the Newly Registered Users group and Yes for the Registered Users group. Then the post count to exit the NRU group would allow people to post links. With that "solution", no Group Wide Setting is needed nor is any new group needed. And that may be sufficient for most users.
The only time that doesn't work is if the Admin wants different post counts for the NRU group and the ability to post links. Then we're back to this discussion.
Pony99CA wrote:However, you may not have to have a separate group for each "variable" (or option). If you want several features to turn on with one post, you only need one group (you can use the Newly Registered Users group for now). If you want several other features to turn on after more posts, you can just define one group for that. You'd only need one group per option in my proposal if each option had a different post count from all of the other options.
In your method, you'd need one Group wide settings counter for each item regardless of whether or not the post counts were the same or different. That can get heavy, too, I'd think.
I doubt there's much weight for GWS options other than the few bits it takes up in php file to display them compared to the load from all of the db writes from changing groups more often. Some things make sense with y/n/N, some things make sense for auto groups and something make sense for GWS. I think this one should be GWS.
Every time the user wants to post a link, there will have to be a database read of the Group Wide Settings value (unless that's cached). That's load.
Oh, and what happens in the case when the Admin sets Group A to have a link post count of 10 and Group B to have a link post count of 20 and then assigns a user to both Group A and Group B? What post count applies then -- the maximum, the minimum or the value on the user's default group? (That's a rhetoric question, but you can see that it could be confusing. It must already be addressed for things like the Group private message limit per folder
Group Wide Setting, but I wonder if the correct answer would match what you expect.)
Pony99CA wrote:One more thing. You mentioned conflicting permissions. I agree that your proposal would probably be easier for new users to understand. Mine requires a decent knowledge of how phpBB permissions work, which can confuse new users. However, once they get permissions, mine will be much more flexible in the long run.
Perhaps...but at the cost of bloat and load. I'd rather have pages and pages of options in the ACP than the cost on the server.
People already complain about the complexity of the ACP, and you want potentially pages
of more options rather than even a little (and I'm not saying that Auto Groups would only be a little, mind you) extra load? I may potentially be bloating the run-time load, but you're potentially bloating the user interface. Servers get faster every year, memory gets cheaper every year, so heavy load this year may not be heavy next year. User's don't get much smarter every year.
Plus, you still haven't addressed the development cost of adding new post-count-based permissions. With Auto Groups, they come along for free. With your suggestion, somebody has to implement each one, either a developer in core code or a MODder as an extension. That means an Admin who wants a specific post-count-based permission has to either develop it himself or wait for somebody else to do it. In my opinion, the flexibility and extensibility of Auto Groups justifies at least some
load. How much is a developer's call, of course.
Anyway, I don't think that I'll convince you of the rightness of my solution and you obviously haven't convinced me of the benefits of yours, so how about we agree to disagree and see what other users prefer? Maybe a developer could even chime in with their opinions on load and development time.