Luke

The $25 ever 6 months for standard, $30 per year for perpetual, and nothing for lifetime isn't just support. It includes access to the resource site which is considered a service. I never said that I wouldn't be willing to pay something as a lifetime license holder. But their current reasoning is not justified. Either give it to all license holders, or don't. It's is simple as that. I hope you can understand now. Thanks Matt. I await your answer :).

I think it was around $150 when yearly licenses were about $60. I know I paid $200 or more for my lifetime license when it was available. I don't recall the exact amount. But as I said before, it's not about what you paid for the license, or how much you pay to renew it. A license is a license, and should be considered equal. They should be giving it to all license holders, or make it separate service. I'm not against paying something to help with the costs of running this service (as it seems to be their concern), I just don't appreciate their initial tactic. They're talking about it, so we'll wait. But I expect nothing less than equal treatment for every license holder. What ever is/was paid for a license should not be put into the equation.

bfarber: The way I see it is the standard license $25 fee is for support and upgrades, nothing else. If you bend it to "future services" then by that token you should do it to the perpetual license since they pay $30 per year for support. And if you give it to them, lifetime license holders should get it free. The closest thing I have to compare to this service is the resource site: Without an active support contract, you cannot access it. Standard license holders pay $25 every six months, perpetual license holders pay $30 per year, and lifetime license holders pay nothing. But they get access to the same "service". And technically I would consider the resource site a "service" the same as the spam monitor. I ask for every license holder to get it, or for none of them to get it and have a yearly fee. That would be fair to everyone. And it's much simpler to charge no one, or charge everyone. And as far as who is paying what for their license, in order to be fair you can't look at that. Regardless of what the initial agreement was, a license is a license. I have an active support contract, I get access to the resource site "service". The spam monitor should be treated the same for all, or different for all. It's as simple as that.

This is the way I see it: You should have known full well you were going to piss a lot of people off by telling them that lifetime/perp license holders could not use this service, and that they could one-way convert their licenses to a standard license to use this service. Especially given the nature of the service: A way to stop spam, something that should be a stock feature available to everyone. I'm sure you talked about it for a while, but I can't believe it didn't cross someone's mind before posting the announcement. If you have retracted the statement and are working on it further, an ajustment to the annoucement needs to be made. As I've said before, a license holder is a license holder. You can't discriminate one from the other, regardless of what the arrangement was. If you are extending the support fee for this, you should do it for the other licenses as well, regardless of who pays what. I also know that by giving it to the standard license holders, you are not increasing your revenue by any margin to cover the costs of the server required for this service. This leads me to believe that it is not about cost, but a way to get people to convert their licenses. If you still wish to honor them, honor them. If this is about cost, charge for it. And if you do, charge everyone, not just perp and lifetime license holders. How ever you want to do it, I'm sure no one would complain. $10 per year provides an access key for every form license, $5 per year per access key, etc... what ever it is, I'm sure no one would mind. But if you want to have everyone use it, it has to be dirt cheap. You want everyone to use it, but excluding lifetime/perp license holders does not do that. It just pisses them off, and they refuse to use the service. Be fair accross the board. That's all I ask.

You have to understand something - you pay $25 every 6 months for support. If that is extended to this service, then by that logic the perpetual license should also get the service because they pay $30 per year, regardless of who pays what. They are extending that $25 to the service, so they should extend the $30 to it as well (I thought it was $60, sorry don't have a perp lic.) As they said this is about covering costs. If that's true, then what's wrong with giving it to lifetime license holders for free? And by the same token if they don't want to do that, they should charge for it separately for everyone, not just perpetual or lifetime license holders. You can't force us out of our licenses, and you can't make special clauses excluding specific license holders from the service. A license holder is a license holder, regardless of what the arrangement is. Be fair about it across the board. Another argument I make is this: Why is this service needed? What was the need to create such a service? The answer is the methods for preventing spam bots from registering on the site are becoming ineffective. Every day bots are getting better and better at breaking through CAPATCHA barriers. If a service is the only thing to prevent spam, I see it as a replacement of a feature that is already under the terms of my license. Again, I understand there are costs involved with running a server and that there must be a ton of people with perpetual licenses and lifetime licenses. Since this seems to be an extension of the support contract, just like access to the resource site, perpetual customers are already paying something for it. If you can't bare to have lifetime license holders to get it free, find another solution outside the support contracts.

Ok. I just wanted to make sure the horse was dead :P. I just want them to be fair about this... if this is really considered something separate, then they need to charge for it separately. If it's purely for costs, I'm sure a low yearly fee would suffice. That's how I feel about it :)

All I've read so far is the first couple pages and the announcement. And the announcement says that they can "convert" our license to a standard license in order to use the service. I find that unacceptable. Also, don't perpetual customers pay $60 per year for support, or something like that? Just what is the difference between that and $25 every six months? Why the need to exclude perpetual license holders if they pay the same support fee (in fact, more)?

I apologize in advance as I do not have time to read seven pages of replies. Having a lifetime license, I feel insulted that in order to use this service I have to give up my lifetime license and convert it into a "standard license". I feel that this tactic is shameful, and dishonorable. On the other hand I do understand it takes resources to run a server for this, and there are costs involved. That is why I feel that if you need to exclude lifetime/perpetual license holders (which perpetual do pay support fees too), then you should exclude all license holders and establish a low monthly fee to the service. As you pointed out, this is a debate of apples and oranges. It's a separate optional service for IP.Board, thus it should be treated as such.

Ok now... seriously why do people (may be just you) keep using the spoiler tag for almost every post they make? If you saw a movie that someone has not seen and didn't want to spoil certain details, that's what it's for. Otherwise the use over-use of the spoiler tag on this forum is getting irritating.

The help files would be very difficult to make language selectable. The only real way to do this would be to catagorize each help article by language and for you to add the same articles for different trasnlations. The rest of the things like custom field titles, rank titles, and user group titles: The report center had a solution for this by having run-time replacements. You could do something like {ipb.lang['LANG_KEY']} and it would replace this with the correct language bit. I'm sure that it's been removed in the IPB 3 version though. But a similar approach could be used. Something like {lang:member_group} using a simple strpos/stripos would be sufficient. Obviosly you'd see this in the ACP instead of the actual title (like you would see {lang:member_group} instead of "Members" for a group title).

cool :)

Is the subscription manager going to be completely separate? I mean I know it's an application, but do you have to download it separately from the IPB download? I would think this is the case, which I personally wouldn't have a problem with.

That really annoys me. Thankfully I can hit command (ctrl on windows) and open the full editor in a new window :)

I personally wouldn't mind an RC3.

I would suggest IN_DEV be in each wrapper so they can be toggled separately.

It's not that simple. You can't cache the results because of permissions. One user viewing the profile may not have access to posts in a particular form, so the results would be different from user to user. Right now IPS is focusing on eliminating bugs that prevent intended use of the application. After that, they can spend time auditing the queries changing/adding necessary indexes to improve performance. It's really a matter of making sure that file sorting is not occurring, if possible. One thing I do recommend them doing though is having some sort of archiving system for the posts and topics table. With large boards these tables (the posts one especially) gets really large. In effect, the indexes get really large. The purpose of these indexes is to speed up access time. When the indexes get really large, this really defeats their purpose. A way to solve this is by moving outdated posts and topics to a "posts_archive" and "topics_archive" table, which would be almost identical to the originals. Posts a year old or more (configurable) would be moved to this archive table. The main tables would be used by the community, then when a topic falls off the face of the earth, it gets moved to this other table. The thing that usually ends up happening is posts table get really large, and admins end up pruning them to improve access time. If there was an automated archiving system in place, old data could be kept, but in another less active table, and it could happen automatically. Admins would never have to prune again, and data is kept. Essentially archived posts would not show up in the pagination (just like you can limit the pagination now). Searching would not show these archived posts, unless a "search archive" option is enabled. Viewing posts with the standard link with cause a 301 redirect to a link with an archived marker in it. Posting a reply would move it to the active table, unless an admin has an option to not allow archived topics to be bumped. Archived topics/posts would also not show up in profiles. That would really improve performance for large boards ;)

Yeah, I just noticed there was just a plus button, and I thought it was quite odd. That's what I was wondering. It took a little bit of searching, but I managed to find a post from bfarber that said something to the effect that you can enable/disable negative and positive reing separately (he was answering a question about changing votes).

I'm not sure if this is a bug, or just an additional option that they're testing, but there is no minus button on posts. Is this on purpose? Is this an option that you can turn on or off?

Well, as I said it is limited. But it would be a viable alternative as it's something already being tracked by the browser. From a user aspect it may not be as convenient, but it would be still usable. Most users use one browser anyway (unless you're a developer), and a lot of people don't clear their history. If they did, it would be a penalty they'd have to deal with. And I'm not saying it should be the solution, but rather an option for improving performance on large boards. I know topic markers are still being somewhat worked on, but when it's optimized to be the best it can be, along with everything else, I wonder what he benchmarks would be with topic markers completely turned off (without the joins). I'm really not suggesting this be implemented now or anything. I'm just trying to keep an open mind and suggest any alternatives that pop into my head :) .

Ok, so the idea behind the topic markers is to allow a user to see what they have read, and what they haven't read. This is supposed to work when they are logged in no matter what computer they are on, etc... I can imagine that with the complexity of how it works, it can cause quite a bit of overhead, correct? In effect, I'm really not suggesting that the concept be changed. What I am suggesting, however, is a "performance" alternative using something that already exists: browser history. Most browsers, if not all, will keep track of which page (topic) you've visited. With CSS you can specially design a link tag that has been visited, and what is inside that link tag. Why not have an option to rely on the users browser history? All you would have to do is include a unix time stamp in the url using the topic's last_updated date. Then when a new post is added, the url changes, thus it's no longer considered "read" to the user. The same can be used with the board index (if the date passed doesn't match with the topic, you could initiate a 301 redirect). Now I realize that this isn't the most desirable way of keeping track of read topics. If a user were to clear their history or use a different computer topics that they've already read would show up as unread. But if you have a pretty hefty board, it may be a good viable option. What do ya think?

I know that many areas of the board pull the language bits from the language pack system directly, but for cases of menu's generated by tables, etc... what about an on-the-fly alternative? Like {lang:my_lang_bit}. That way anything that pulls in dynamically can be abstracted. You wouldn't even have to use a regular expression to accomplish this. You could do something like: while(($pos = strpos($html, '{lang:', isset($pos) ? $pos+6 : 0)) !== false) { if(($endb = strpos($html, '}', $pos)) !== false) { $key = substr($html, $pos+6, $endb-$pos-6); $html = substr_replace($html, 'LANG['.$key.']', $pos, $endb-$pos+1); } else break; } (code above is a working example. replace 'LANG['.$key.']' with the language bit using $key)

Just wanted to point out that there is a difference between "Opera Mini" and "Opera Mobile". For testing with Opera Mini, you can use this: http://www.opera.com/mini/demo/

The "redirect form" is good for sending certain topics anywhere you want, but the only useful piece of information it shows is how many "hits" that link has gotten. Since the board index stats are cached, it would be neat to have an RSS option for the form redirect to pull in details similar to actual form categories. This could be useful if you wanted to pull in information from the bug tracker and show the last bug report replied to, how many bug reports there are, and replies, etc.... You could make the bug tracker seem like it's a form category. But since it syncs with RSS, you could do this with just about anything :) .

Your solution is acceptable, however, the purpose behind the routine under: //----------------------------------------- // Run through and delete dead msgs //----------------------------------------- .. is to flush out all message_text entires after they no longer have a linking message_topic. If this is causing a problem, realistically you could take out that entire block and move it into it's own function and run it on a daily task rather than having it occur on every delete action. The reason being that after a topic is deleted, it can't be seen anyway and it doesnt have to be deleted immediately. Then again with the way msg_deleted_count works, if you deleted a topic manually through phpMyAdmin, that part of the code wouldn't pick it up anyway, thus defeating the purpose of it grabbing "dead" PM's. If put on a task, you'd have to check the topics table instead.

Ok..... We have this form that was a general topic for a certain area in the game we're a fan site of. We had to split this into four different groups and sort through the topics, moving them into the appropriate form. There are several things I noticed about this that I wish would change or be added: 1) The checkboxes need to be a little more pronounced. Having a blue vs red check isn't helping. A regular checkbox or a graphic that has an empty box vs checked box would be a little more obvious. Think about people who are color blind... I'm not color blind, but even I have a hard time when I'm glancing. I could change this on my own form, which I plan on doing, but it should be default as a lot of skinners just use the default graphic for this. 2) When moving topics or doing some sort of action on a bunch of topics, the new feature that keeps track of what you checked on previous pages in very useful, and I'm glad that feature exists now (as it had not before). Problem is I go to move it and I accidently hit the button, which the default option is "Close Topics". Since what I'm doing is tidius, it can be very irritating to have to go back and unlock those topics. I would suggest two things to alleviate this: A) Have the drop down remember the last action. If I just moved a topic, have the default be move topics. B) When you get to the move topics page either select the current form as default, or remember the last form you moved topics to. That way if you're moving topics to the same form, you don't have to select it every time. Or if it's close, you don't have to go very far to change it. For smaller forms it's not as bad, but when you have a ton of sub-topics generated over the years, it can be a pain sometimes. 3) Checking the boxes on the right can be a little annoying when you're looking at the topic titles on the left. Makes checking topics a bit cumbersome. I could move the checkboxes to the left, but when I want to get through topics quickly, I'd rather have some sort of shortcut. I know that in the past we've had key combinations, so something like Shift-Click on the topic title to check a topic would be cool. Of course a neater thing would be to add key word search to the Mass Prune/Move tool.