View Issue Details

IDProjectCategoryView StatusLast Update
0003281unrealircdpublic2012-11-25 17:45
ReporterstskeepsAssigned Tonenolod 
PrioritynormalSeverityfeatureReproducibilityN/A
Status resolvedResolutionfixed 
PlatformAllOSAllOS VersionAll
Product Version3.3-alpha0 
Target VersionFixed in Version3.4-alpha1 
Summary0003281: Removal of masked channels
DescriptionShould we remove or implement masked channels properly? My vote goes to removal.
TagsNo tags attached.
3rd party modules

Relationships

parent of 0003279 resolvedstskeeps /invite and masked channels 
parent of 0003278 resolvedstskeeps Channel names shouldn't allow two colons in them 
parent of 0003277 resolvedstskeeps Pseudoservers don't match channel masks 
parent of 0002728 resolvedstskeeps Channels like #:irc.someserv.net cannot be handled by services or other servers(??) 
parent of 0003283 resolvedstskeeps Masked channels in /list 

Activities

Shining Phoenix

2007-04-18 04:41

reporter   ~0013493

It's more done than not done, so why stop now? Channel masks must have a serious use, I just don't know it yet. Someone else might.

stskeeps

2007-04-18 04:46

reporter   ~0013494

A huge problem with masked channels is that well, they are horridly difficult for services, for instance, and the channel mask code just clutters up the code, in my opinion, and i have never seen a proper use for them :P Admittedly my idea could be that they can take over local channels functionality, but .. yeah. Give me good reasons to keep it and why it is at all useful? A channel that is spread across the network is just as okay?

w00t

2007-04-18 04:54

reporter   ~0013498

Last edited: 2007-04-18 04:54

Masked channels:

Local channels were removed a long time ago, and a number of years ago, I could see the point for local channels (and therefore masked channels). (My reason was stupid, and pointless, and debated on some long closed bug on here).

These days, I don't. Especially when the majority of networks are sub-200 user networks. It's not worth the code complexity when half the users won't know they exist, or won't understand how they work, and it's not worth majorly fucking with services packages the way it does.

If a *valid*, useful suggestion for these can be found, then perhaps they should be kept, but I can't think of any. :)

(vote: Remove)

vonitsanet

2007-04-18 18:03

reporter   ~0013544

who needs masked channels?
My vote: Remove them

aquanight

2007-04-18 18:31

reporter   ~0013546

I'm also voting remove, or possibly #ifdef out controlled by #define ENABLE_MASKED_CHANNELS, for example.

WolfSage

2007-04-18 19:13

reporter   ~0013555

Last edited: 2007-04-18 19:15

Local channels still exist, and I kind of like them =x

stskeeps

2007-04-19 02:22

reporter   ~0013574

Two official coders voting for removal - I think we can deem we're getting rid of these.

2007-04-24 18:31

 

r_channel_masks.patch (6,153 bytes)

WolfSage

2007-04-24 18:33

reporter   ~0013668

Think that covers everything. Just did it up quick (I need sleep. Now.)

Channels such as #:, #::, #test:meh:ness are now legal. UltimateIRCd allows such channels, I assume they're safe but I haven't read the RFC's in forever ;)

stskeeps

2007-04-25 04:53

reporter   ~0013677

Syzop wanted :'s still banned in channel names, as services will bitch about them? (Can someone verify services does this?)

WolfSage

2007-04-25 06:46

reporter   ~0013680

Anope can handle channels containing ':' just fine.

stskeeps

2007-04-25 06:48

reporter   ~0013681

We should probably note that this change is not backwards compatible, and might break on non-3.3 servers.

WolfSage

2007-04-25 07:19

reporter   ~0013683

Last edited: 2007-04-25 07:21

IRCServices works with this fine. (Thanks nate!)

Note: This is not backwards compatible and might break non 3.3 servers.

stskeeps

2007-04-25 11:40

reporter   ~0013691

Patched in .2378, feel free to find things that we have missed still regarding this issue.

syzop

2007-04-26 06:08

administrator   ~0013726

personally I would just disallow the : character in 3.3*. I don't see why to risk all the breakage just for being able to use one silly character (not to mention #channel.xx is much more popular than #channel:xx)

Anyway, this issue isn't that important for me...

Oh and yeah, I was ok with removal.

wolfsage: you sure about anope?

WolfSage

2007-04-26 09:11

reporter   ~0013736

Dead positive ;)

syzop

2007-04-29 16:44

administrator   ~0013928

rethinked and.. IMO not a good idea to allow :'s, committed:

- Disallowing channels with : in them, it's not worth to risk breakage of 32* to 33*,
  services, and other things like odd-extbans and things we haven't thought about,
  all for allowing one silly character.

this should get rid of all worries.

vonitsanet

2007-04-29 18:02

reporter   ~0013932

+1 to syzop

stskeeps

2007-06-22 05:52

reporter   ~0014408

Removed, as far as I'm concerned.

nenolod

2012-11-25 17:44

reporter   ~0017243

Re-ported to 3.4 tree.

Issue History

Date Modified Username Field Change
2007-04-18 02:33 stskeeps New Issue
2007-04-18 02:34 stskeeps Relationship added parent of 0003279
2007-04-18 02:34 stskeeps Relationship added related to 0003278
2007-04-18 02:35 stskeeps Relationship added parent of 0003277
2007-04-18 02:35 stskeeps Relationship replaced parent of 0003278
2007-04-18 04:41 Shining Phoenix Note Added: 0013493
2007-04-18 04:46 stskeeps Note Added: 0013494
2007-04-18 04:54 w00t Note Added: 0013498
2007-04-18 04:54 w00t Note Edited: 0013498
2007-04-18 04:57 stskeeps Relationship added parent of 0002728
2007-04-18 05:01 stskeeps Status new => feedback
2007-04-18 05:26 stskeeps Relationship added parent of 0003283
2007-04-18 18:03 vonitsanet Note Added: 0013544
2007-04-18 18:31 aquanight Note Added: 0013546
2007-04-18 19:13 WolfSage Note Added: 0013555
2007-04-18 19:15 WolfSage Note Edited: 0013555
2007-04-19 02:22 stskeeps Note Added: 0013574
2007-04-19 02:22 stskeeps Status feedback => confirmed
2007-04-24 18:31 WolfSage File Added: r_channel_masks.patch
2007-04-24 18:33 WolfSage Note Added: 0013668
2007-04-25 04:53 stskeeps Note Added: 0013677
2007-04-25 06:46 WolfSage Note Added: 0013680
2007-04-25 06:48 stskeeps Note Added: 0013681
2007-04-25 07:19 WolfSage Note Added: 0013683
2007-04-25 07:21 WolfSage Note Edited: 0013683
2007-04-25 11:40 stskeeps Note Added: 0013691
2007-04-26 06:08 syzop Note Added: 0013726
2007-04-26 09:11 WolfSage Note Added: 0013736
2007-04-29 16:44 syzop Note Added: 0013928
2007-04-29 18:02 vonitsanet Note Added: 0013932
2007-06-22 05:52 stskeeps Status confirmed => resolved
2007-06-22 05:52 stskeeps Fixed in Version => 3.3-alpha0
2007-06-22 05:52 stskeeps Resolution open => fixed
2007-06-22 05:52 stskeeps Assigned To => stskeeps
2007-06-22 05:52 stskeeps Note Added: 0014408
2011-07-19 14:04 syzop Assigned To stskeeps =>
2011-07-19 14:04 syzop Status resolved => needs re porting
2012-10-16 11:01 syzop Severity major => feature
2012-11-25 17:44 nenolod Note Added: 0017243
2012-11-25 17:44 nenolod Status needs re porting => resolved
2012-11-25 17:44 nenolod Fixed in Version 3.3-alpha0 => 3.4-alpha1
2012-11-25 17:44 nenolod Assigned To => nenolod