CService notice and bandwidth

[Eenie]

I have not been a supporter for a new channel for a very long time, but I am currently a supporter for a channel undergoing the registration process. I am surprised to learn that CService notices the channel EVERY HOUR that:

-channels.undernet.org:#<channelname>- This channel is currently being processed for registration. If you wish to view the details of the application or to object, please visit: http://cservice.undernet.org/live/view_app.php?id=<number-here>

This goes on every hour for days and days while the channel awaits the registration decision. Not only is this extremely annoying to the channel users, but I suspect it is a waste of bandwidth, since many channels are undergoing the registration process at any given time.

Perhaps instead of this persistent channel notice, CService could state that same thing in a locked channel topic for the channel? Seems to me that would use less bandwidth and would certainly reduce the annoyance factor for channel users.

In the meantime, I have installed a small command in my mIRC remotes so I do not have to see the notice. For those interested, it is:

on ^*:NOTICE:*registration*:#:{ if (. isin $nick) haltdef }

Just hoping my suggestions are helpful,
Eenie

[sirAndrew]

Eenie that`s a good point, the notification period takes up to 3 days even using thejudge, however thejudge can be configured and this period could be shorthen.

But i don`t think that the notification period will be changed or excluded from the registration process for a few good reason.

1: If notification would be disabled a channel could be registred in about 2 hours using the judge....why?! Well because the incoming stages takes up to 3 days but it can be passed in 5 minutes if all supporters are online and at the pc. The traffic check also takes up to 3 days. But the update on the website is done every 60minutes, if the supporters make enough traffic in 30 minutes to pass the traffic check, the channel can make it to the next stage which is notification only. This is stricly a 3 day stage that cannot be shorthen unless an admin decides to accept the application manualy. If all is ok after this stage thejusge will register the channel.

Now if coders would disable this stage after the traffic check thejudge would registered the channel. And it could take about 2 hours. Before thejudge was implemented, the regproc took 10-12 days as admins needed to review every application one by one which took too long. Now using thejudge a smart and experienced user can register a channel in 5-6 days only if noone posts an objection. The period is short enought already, Cservice will never accept the ideea that a channel can be registered in 2 hours.


The second but not less important reason would be that rewriting the gnuworld and making the regproc to set a topic instead of noticing would need more resources and more time to configure? Why? Easy? The same time gnuworld, makes the traffic check updates on the website it also notices all the channels that are in the notification stage. For gnuworld to changes topics, locked ones it would need a new channel mode or something like topic lock....it`s better as it is now.

Or an ideea would be is coders could split the noticing process from the traffic check updates, so that the traffic check updates would be done every hour the same way it is now, but the notification would be done once, twice a day exactly at the hour the application was posted, because noticing every hour it`s annoying...it just noticed the same thing 24 times a day, 3 days per notification stage. You do the math....

[Eenie]

SirAndrew:

I never suggested, hinted at or impied that I wanted the notification PERIOD changed.

I simply suggested that CService use the same notification METHOD it uses for new channel manager vote in channels where they need a new channel manager. In this instance, they lock a topic in the channel for a set time to give the ops a chance to vote.

If this suggestion cannot be implemented because of some complicated procedure already in place, then either change it or forget my suggestion.

Those mIRC users whom it annoys can always use the command I gave to ignore the notices.

Eenie

[sirAndrew]

That`s a whole other story because the channel is registered, and they lock all the setting not only the topic, users cannot be removed or added, and they cannot change any channel setting....I wanted to say in my other post that in other to lock the topic, Cservice would have to implement another bot that will stay in the channel and prevent users from changing the topic

[Mitko]

That would mean recoding something in GNUWorld, but still, topics are not bursted after net split so it would be a problem. Anyway, changing the period would be the best if you ask me. One or two notices per day would be fine. Sometimes the registration proces takes ~ 5 days, so lets redo the math. ( 5 * 24 = 120 ) That means, 120 notices in less than a week if you are a supporter of a channel. If you ask undernet users with scripting knowlegde, mIRC, irssi, xChat etc, who were supporters of a channel, you'll see that many (if not everyone) of them is coding script, or simply ignores the channels.undernet.org to prevent that harassment. Indeed, harassment. So, it might be considered that Cservice is annoying and harassing the users who are registering a channel. As a reason of disabling (or not enabling) some IRCu/GNUWorld features was the bandwidth 'problem'. Think about that.


Best Regards,
Mit

[xplora]

First of all, the notification stage is a fixed 5 days, the only way it is ever shorter is if it gets rejected during that time.

Secondly, since X is not in the channel yet, there is no method to lock the channel topic.

and,
Lastly, I agree it is a waste of bandwidth, but it is also about the only way to make sure we get EVERYONE that is part of the channel a chance to be able to object to the application, the only way we could improve on that detail is to make it more often :(

[xplora]

As far as the current use of topic locking for things like missing managers, we aren't trying to notify everyone, just those with access in X, and there we can claim it is their responsibility as part of the channel to take notice of such things.

[sirAndrew]

I registered my channels in 6 days..and the notification took less than 5 days, an ideea about that is to ask the coders what is the real period they set, and how or if it can be shorten.

However getting back to the topic, the best ideea is to make it less often, not more often xplora....every hour is too much, however that would as i said required a little coding to split the website join count update from the notification sistem.

[wulf]

As xplora said, the point is to notice every regulars the channel is being registered. Not everyone idle on the channel all day long. Regulars can be user joining only 1-2 hours per days then quiet and they wont know channel is currently being registered if notice are not sent often enough. Therefore a channel could be registered in error to someone not being the legitimate manager if regulars didnt knew he sent an application.

Also notifcation is always 5 days. it is possible that a channel got registered in 6 days, this mean all supporters confirmed and there was enough traffick within only a day... unless an admin approve an application manually before. But thats really rare and exeption case.

[Mervin]

Waste of bandwith?
Even if there would be 100 channel applications at the same time in Pending (notification) stage... there would be about 2400 notices like those sent per day.
You call this a waste of bandwith? What about thousands of commands that are getting sent to X every minute?

[xplora]

I registered my channels in 6 days..and the notification took less than 5 days, an ideea about that is to ask the coders what is the real period they set, and how or if it can be shorten.

However getting back to the topic, the best ideea is to make it less often, not more often xplora....every hour is too much, however that would as i said required a little coding to split the website join count update from the notification sistem.

6 days included 5 days notification, the only way it was faster is if you either used background connections to register it faster, or X was netsplit at times you were online duing it therefore couldn't see the notices.

as far as less often, someone else has already answered that, and note, as I said in my last post, the only way to improve on this system is to make the notices more often, not less :/

[The-Judge]

As Mervin sad...Waste of bandwidth ? Neah...there is no such a problem when we talk about those notices.
Is true that those notices are really annoying, but those notices are really important for a channel registrations. Let's say that the real manager of a channel is on vacation. He comes back home and notices that his channel is under registration(by those notices) and the notification period is at the end. What he would do if those notices weren't there?
My opinion is that those notices are really good as the are now. You can always ignore "channels.undernet.org" if you don't know mIRC scripting.

[Crosswing]

You can always ignore "channels.undernet.org" if you don't know mIRC scripting.

/ignore does not stop the notice to get to your client, it just prevents it from being displayed. There is no way to stop it, because it's a channel notice (except by leaving the channel). And it's not a waste of bandwidth, but talking about it is.

[Eenie]

This is a very old topic, having been opened by me over 7 months ago.

And there IS a way to not have to see it; I posted it in the original opening:

In the meantime, I have installed a small command in my mIRC remotes so I do not have to see the notice. For those interested, it is:

on ^*:NOTICE:*registration*:#:{ if (. isin $nick) haltdef }

I think it is time to lock this old topic.

Eenie