Anope IRC Services

Please login or register.

Login with username, password and session length
Advanced search  

News:

Pages: [1]   Go Down

Author Topic: 328 RPL_CHANNEL_URL Support  (Read 8245 times)

0 Members and 1 Guest are viewing this topic.

Swampy

  • Guest
328 RPL_CHANNEL_URL Support
« on: June 06, 2008, 03:53:31 PM »

328  RPL_CHANNEL_URL    Support in Anope
(reference: http://www.alien.net.au/irc/irc2numerics.html#328 )

Anope Services could support this mode, it will show the Channel's URL on entry and also inside the Channel Settings dialog.

Could this be added by way of a module?, or would it need adding to the core?

Many Thanks

[Edited on 6-6-2008 by Swampy]
Logged

Jan Milants

  • Team
  • *
  • Offline Offline
  • Gender: Male
  • Posts: 1372
(No subject)
« Reply #1 on: June 06, 2008, 05:55:57 PM »

the only IRCd that supports RPL_CHANNEL_URL  and is supported by Anope is Bahamut... dunno if it s worth it considering this wouldn't work on UnrealIRCd nor on InspIRCd support this..

[Edited on 6-6-2008 by Viper]
Logged
If you like me donate coins to 1FBmZVT4J8WAUMHKqpWhgNVj3XXnRN1cCk :)

katsklaw

  • Guest
(No subject)
« Reply #2 on: June 06, 2008, 07:38:16 PM »

I fail to see what will be gained to be honest, 328 is an ircd to client thing which means that when a user joins a channel, the local server sends 328 as part of the clients synch process which is done before Anope even knows the client as joined a channel and since services doesn't allow client connections, it's a rather moot point to support it.

In my personal opinion sending the URL every single time a user joins a channel is more resource intensive than simply sending the URL upon request, ie /cs info.
Logged

Jobe

  • Contributor
  • *
  • Offline Offline
  • Gender: Male
  • Posts: 1023
    • Anope IRC Services
(No subject)
« Reply #3 on: June 06, 2008, 07:38:22 PM »

In theory, numeric responses should be sent on regardless of whether they exist or not, but in practice they're not.
Logged
Your IP: ()
My IRC Status:

Come along and visit http://www.anopequotes.org/

katsklaw

  • Guest
(No subject)
« Reply #4 on: June 06, 2008, 08:35:40 PM »

Quote
Originally posted by Jobe1986
In theory, numeric responses should be sent on regardless of whether they exist or not, but in practice they're not.


this applies to ircd's that accepts client connections. This is for the clients benefit, since services doesn't allow incoming client connections it's not subject to this theoretical practice. Again, 328 comes from the LOCAL ircd.

RFC1459 mentions numerics for s2c use, there is no RFC that mandates s2s protocols, which is the only traffic that applies to services with the exception of replying to a clients direct request, such as motd, stats, version .. etc.

[Edited on 6-6-2008 by katsklaw]
Logged

Swampy

  • Guest
(No subject)
« Reply #5 on: June 08, 2008, 03:51:51 AM »

Well after talking to a guy "in the know" (ive edited his name) about services, he told me this in my IRC:

<GUY_434>   seems as if the anope lot are stuborn as hell
<GUY_434>   Theia sends the numeric from its local pseudo server
<GUY_434>   If you have a umode to view which server what comes from
<GUY_434>   You'd see numeric 328 coming from services, not the IRCd
<GUY_434>   The statement that it has to come from the local IRCd is bullshit
<GUY_434>   Services it technically a linked server aswell
<GUY_434>   I've checked over the atheme source, it does 100% support channel URLs on unreal

<GUY_434>   This is how atheme does it
<GUY_434>   if (u->server->flags & SF_EOB && (md = metadata_find(mc, METADATA_CHANNEL, "url")))
<GUY_434>   numeric_sts(me.name, 328, cu->user->nick, "%s :%s", mc->name, md->value);

<GUY_434>   This is what theia now does, but didn't originally
<GUY_434>   toserv(":%s 328 %s %s :%s\n",
<GUY_434>   Me.name,
<GUY_434>   lptr->nick,
<GUY_434>   chanptr->name,
<GUY_434>   cptr->url);

<GUY_434>   As far as I can see in anope, there is no entry for 328 at all
<GUY_434>   It would have to be directly coded into the channel.c file
<GUY_434>   Since anope doesn't even know what numeric 328 is
<GUY_434>   The anope guys made a big mistake, They hardcoded the numeric types
<GUY_434>   Instead of allowing you to specify it in what you send to the server
<GUY_434>   atheme in a way also did that, but they didn't make it over-complicated

[Edited on 8-6-2008 by Swampy]
Logged

katsklaw

  • Guest
(No subject)
« Reply #6 on: June 08, 2008, 05:10:43 AM »

This topic has been discussed as far as it can be constructively discussed. Anope is currently under a feature freeze so no new features until after Anope 1.8 stable is released. If the devs so choose to add this trivial feature then they will.

What you and your "in the know" buddy, that quite frankly doesn't know is missing is that when any data is sent from any server or client to any server or client, it must go from source to target over at least 1 ircd. The ircd MUST understand the traffic being sent or it will either send an error back or ignore the traffic.

In this case user joins a channel, that join request is sent to the ircd the user is connected to, that ircd checks banlists and channel modes to insure that the user is allowed in the channel, if all is well the ircd the user is connected to begins a sync proccess that includes updating channel timestamps, modes, topics and numerics (in our case 328). All that data comes from the LOCAL ircd the user is connected to, not any other ircd. AFTER the user is synced (usually takes a few milliseconds), the ircd THEN sends the join event to it's uplink server and is passed on to every server that has at least 1 user in the same channel, this is called "broadcasting". Anope will get the join message as well and then can react if needed, such as granting ops, kicking the user and setting a ban because the user matches an akick entry, send entrymsg ... etc ..

That said, Anope can be written to send 328, BUT ONLY TO IRCDS THAT KNOWS WHAT 328 IS!! Currently only 1 have 328 that Anope supports. That's bahamut. That means that if Anope tries to send 328 on the join event on an ircd that doesn't support 328, such as Unreal, then the message is ignored by services uplink server and it never makes it to the target.

To answer your original question, yes .. a 3rd party module can be written to send the channels URL using numeric 328 to users when they join, bearing in mind that this will take place AFTER the join is completed. Bahamut send this data as part of the sync process which takes place BEFORE the users local ircd informs the rest of the network that the user has successfully joined the channel.

Locked.

[Edited on 7-6-2008 by katsklaw]
Logged

katsklaw

  • Guest
(No subject)
« Reply #7 on: June 14, 2008, 03:40:09 PM »

Ok, during the course of additional investigation I've found that at least Unreal will in fact pass on unknown numerics to users. This IMHO is EXTREMELY reckless!

As an apology, I'll write this module.
Logged

katsklaw

  • Guest
(No subject)
« Reply #8 on: June 14, 2008, 05:23:43 PM »

Logged

Swampy

  • Guest
(No subject)
« Reply #9 on: July 01, 2008, 09:55:09 PM »

Sorry to bother you again, but the module didnt work at first, luckily chaz managed to compile it, the module loaded fine after that.

But it's not sending the correct string output, so my client does not recognise it (its sending output to Status window)

If I can explain it better.

It SENDS it currently like so>
{services.chathq.ath.cx} {328} { [name] [Channel] [URL] [for] [#channel] [is] [url] }

I've asked my friend, he says its supposed to send it like so>
{127.0.0.1} {328} { [name] [#channel] [url] }

He then said it would show up in the settings dialog correctly :D


The format of the string should be:  :%s 328 %s %s :%s

:%s is the services server
Second %s is the nickname
third is the channel
forth :%s is the url


Thanks


[Edited on 1-7-2008 by Swampy]
Logged

katsklaw

  • Guest
(No subject)
« Reply #10 on: July 01, 2008, 11:06:27 PM »

There is no official string syntax for this numeric for Unreal as it does not exist. Which was part of my original complaint. you show me in RFC1459 or the Unreal ircd protocol where it states what the proper syntax is, then I'll fix it .. until then you will just have to either fix it yourself or suffer.
Logged

Swampy

  • Guest
RPL_CHANNEL_URL
« Reply #11 on: July 02, 2008, 12:01:12 AM »

It's OK, Viper recompiled it for me, and it works properly now :D
Thanks Viper :)

If anyone else wants it http://chathq.ath.cx/ircd_chanurl.rar (archive has both windows+c file)

The Module Viper recompiled for me works fine, in both XChat (which is a popularly used client) and the ZRC Client. Both work 100% with Viper's compile :D

Yes, me and my friend knows there is no "Official" RFC tables for the formatting of the code, but as you can see from the example, It clearly works better the way my friend suggested.
« Last Edit: September 08, 2008, 03:22:16 PM by Swampy »
Logged

katsklaw

  • Guest
(No subject)
« Reply #12 on: July 02, 2008, 01:32:32 AM »

It always worked properly, what's the deal with you is that you use clients that require numerics to be formated a certain way, where most other and far more popular clients don't care about syntax, they pass the numeric on unaltered as it should be. There are very few numerics that should be parsed in a certain fashion and 328 is not one of them. So don't go blaming the module for the clients shortsightedness.

With those clients that require numeric syntax, you will continue to see this same problem when you use ircd's that doesn't conform to the very select few clients that rely heavily on numeric syntax. They will break every time. The numerics that have official syntax are in RFC1459 and 005, everything else is up to the specific IRCd to handle.

There is also nothing thet even says that the numeric must be 328.

[20:39] [998] Channel URL for #Channel is - http://blah.org

This topic is now closed.

[Edited on 1-7-2008 by katsklaw]
Logged
Pages: [1]   Go Up