29 Jul, 2009, Guest wrote in the 62nd comment:
Unrestrained channel creation would be more accurate. Especially in cases where one mud wants it to connect their dev ports up on some private line. There are more suitable code snippets out there for that purpose. Not much reason for the network to clutter up listings with things like that.
29 Jul, 2009, Kayle wrote in the 63rd comment:
Doesn't really matter now that I've stepped down. *shrug* It's all out of my hands.
29 Jul, 2009, David Haley wrote in the 64th comment:
Quote
But Runter is free to do with it as he pleases until such a time as it does get accepted as the actual IMC3 Protocol.
This doesn't make any sense. Are we or are we not talking about a community protocol? What you have said here is that it is somebody's personal project until the very last second at which point it becomes and official, accepted, actual protocol in practice. I'm sorry, but this just doesn't make any sense to me, and as I said previously I still see no real point spending time on this in the current state.
29 Jul, 2009, Cratylus wrote in the 65th comment:
Kayle said:
The reason IMC2 Server Admins are the only ones capable of making channels is because if everyone is able to make channels whenever they want, the network is quickly filled with hundreds of channels that no one ever uses.
Hokay, let's look at what *actually* happens.
The i3 network I run has the channel policy set forth in the
specification. Any mud can create channels they administer. As
of today, these are the channels on the network I run:
Quote
1, 3d-space, Arch, JammsTest, another_channel, ascii_art, avatar,
blah, bofh, bsg, church, cleric, coffeemud_universe, dchat, dead_souls,
dead_test4, dgd, discworld-chat, discworld-cre, discworld_chat, dutch,
elephant_link, firefly, fluffos, free_speech, french, game, german, havenlib,
igossip, imud_code, imud_gossip, inews, insomnia-chat, intergossip, lpuni,
mage, monk, mychannel, mychannel2, mychannel3, mychannel4, mychannel6,
mystic_dev, nakki, narrator, newbie, nschat, nscre, ooc, plea, pray, serenity,
skylib, sport, test, trivia_games, wizard, xblah, zblah
blah, bofh, bsg, church, cleric, coffeemud_universe, dchat, dead_souls,
dead_test4, dgd, discworld-chat, discworld-cre, discworld_chat, dutch,
elephant_link, firefly, fluffos, free_speech, french, game, german, havenlib,
igossip, imud_code, imud_gossip, inews, insomnia-chat, intergossip, lpuni,
mage, monk, mychannel, mychannel2, mychannel3, mychannel4, mychannel6,
mystic_dev, nakki, narrator, newbie, nschat, nscre, ooc, plea, pray, serenity,
skylib, sport, test, trivia_games, wizard, xblah, zblah
It's a total of 60 channels. As you can see, there
are indeed test channels and useless channels and channels
created due to the person thinking they were making a channel
local to their mud.
About 6 months ago or so I actually went in and deleted about 20
unused channels. Not because they were creating a problem, just
out of general principle.
So, in the three years I've run this network, with literally hundreds
of muds coming and going all the while, a total of some 80 channels
have been created.
It may be that even this number appears ridiculously large, if so
that's your personal call and you're welcome to it. I just wanted to
make sure actual facts were in discussion here.
I'm of the opinion that even hundreds of channels are not an
issue, because the freedom to create those channels outweighs how
unsightly they might appear to you. If unused channels really
are a problem, I'd suggest having a cleanup routine run every
6 months or so.
I think it's important for a network to be as inclusive as possible.
It may well be that you're willing to create any channel for
anyone at any time. But if so, you might as well just let them do
it on their own. Insisting on controlling channel creation just smells
like you feel a need to control everything about how people communicate
on the server, and that everything needs to be official. Let people
communicate informally, on their own channels. Honestly, why would you
even care? We need more "Hi make yourself at home" and less "GET
OFF MY LAWN".
-Crat
http://lpmuds.net
29 Jul, 2009, Kline wrote in the 66th comment:
You could just have a core set of channels and denote all private channels to be treated like radio freqs. One of my games has a radio system in it, it's just a single channel that you tune to diffrent freqs and only hear others on the same freq. If people don't like seeing "[freq:8324] Kline: Hey guys!" you could always add client-side aliasing, as already exists in IMC2.
29 Jul, 2009, quixadhal wrote in the 67th comment:
I just don't see having unused channels on the server as that big a deal, unless the server is poorly coded, or it's running on some embedded system with 2M of RAM or something. How much resources can it possibly take to manage an empty channel?
If it's an issue with a messy display… that's a client issue. Let the client filter out channels that haven't seen activity in X days. If you can't tell when the last posting was to a channel on the list… there's something the spec needs to address!
What data would we like to see in the who listing?
Channel Name (on Server)
Mud of Origin (who created it, and that might be the server itself)
Date Created
Traffic Rate (average)
Last Activity Date
Last Speaker
Current Listening MUDs
Access (public, public read-only, invite-only, private)
Logged (true/false – this is logged on the server, since you can't control the clients)
…probably some other flags and toggles and crap…
So, most of that is set at creation time. The activity and speaker get set whenever something goes across the channel. The listener list gets updated whenever a game joins or leaves (explicitly, not via polling) the channel. The only thing you have to do with an idle channel is update the traffic average every XX minutes. I would guess that such an entry would take up… 1K + the listeners list, which might be 250 entries of around 60 bytes each? So, less than 5K of RAM to hold a channel entry?
If I'm way off here, I'd like to know what else makes it difficult. I don't know much about the current networks or how they work, but I can't see where an unused channel should ever be a problem. If it is, you CAN always expire them after a time and let the next speaker's traffic (or request to join) recreate it.
That would be interesting if it were a peer-to-peer network, as you could vary reception based on how many hops away people are. If two MUDs both use the same frequency, you get to hear the one that's closer to you. Not sure that it would be a good solution, but it would be rather fun and unique. :)
If it's an issue with a messy display… that's a client issue. Let the client filter out channels that haven't seen activity in X days. If you can't tell when the last posting was to a channel on the list… there's something the spec needs to address!
What data would we like to see in the who listing?
Channel Name (on Server)
Mud of Origin (who created it, and that might be the server itself)
Date Created
Traffic Rate (average)
Last Activity Date
Last Speaker
Current Listening MUDs
Access (public, public read-only, invite-only, private)
Logged (true/false – this is logged on the server, since you can't control the clients)
…probably some other flags and toggles and crap…
So, most of that is set at creation time. The activity and speaker get set whenever something goes across the channel. The listener list gets updated whenever a game joins or leaves (explicitly, not via polling) the channel. The only thing you have to do with an idle channel is update the traffic average every XX minutes. I would guess that such an entry would take up… 1K + the listeners list, which might be 250 entries of around 60 bytes each? So, less than 5K of RAM to hold a channel entry?
If I'm way off here, I'd like to know what else makes it difficult. I don't know much about the current networks or how they work, but I can't see where an unused channel should ever be a problem. If it is, you CAN always expire them after a time and let the next speaker's traffic (or request to join) recreate it.
Kline said:
You could just have a core set of channels and denote all private channels to be treated like radio freqs. One of my games has a radio system in it, it's just a single channel that you tune to diffrent freqs and only hear others on the same freq. If people don't like seeing "[freq:8324] Kline: Hey guys!" you could always add client-side aliasing, as already exists in IMC2.
That would be interesting if it were a peer-to-peer network, as you could vary reception based on how many hops away people are. If two MUDs both use the same frequency, you get to hear the one that's closer to you. Not sure that it would be a good solution, but it would be rather fun and unique. :)
29 Jul, 2009, Koron wrote in the 68th comment:
I'm confused. Why are we talking about worthless channels? If a custom channel has no one talking on it, just have the server automatically delete it. If you let muds create their own channels, it's no big deal to let them recreate them when they get devoured for inactivity. Whoop-de-doo, not worth getting hot headed over.
29 Jul, 2009, Runter wrote in the 69th comment:
David Haley said:
I'm sorry, but this just doesn't make any sense to me, and as I said previously I still see no real point spending time on this in the current state.
Then don't spend a second more of your time.
That being said it doesn't look like this is going to be the IMC3 protocol. I'm going to continue to develop it and anyone who wants the code (server, client, and documentation) just needs to contact me. I'll likely release it at some point in the future when it's more complete, in any event.
30 Jul, 2009, Tyche wrote in the 70th comment:
Cratylus said:
I2 and Zebedee are protocols that do not use the client/server paradigm
the way I3 and IMC2 do. A distributed network (as I view it. Tyche may
mean something else) would have members joined in a peer-to-peer
arrangement, with no single point of failure. This setup is obviously
terrifying to fascists because it's a surrender of control. If even
allowing channel creation is too wild and crazy, a distributed network
is obviously not worth even discussing.
Kayle said:
Elaboration please?
I2 and Zebedee are protocols that do not use the client/server paradigm
the way I3 and IMC2 do. A distributed network (as I view it. Tyche may
mean something else) would have members joined in a peer-to-peer
arrangement, with no single point of failure. This setup is obviously
terrifying to fascists because it's a surrender of control. If even
allowing channel creation is too wild and crazy, a distributed network
is obviously not worth even discussing.
Networks (channels) are topological
rings of peer connected nodes, public or
private, single or multiple owners.
Network discovery is promiscuous
or not depending on the node owner.
Certainly it accomodates fascist,
democratic, or anarchistic groups.
03 Aug, 2009, Davion wrote in the 71st comment:
Moved to a much more suitable place ;).
03 Aug, 2009, Runter wrote in the 72nd comment:
This has been adopted as the official IMC3 protocol. I'm discontinuing work on YAIMC. I will now be developing the protocol for the sole purpose of IMC3. From this moment forward all final decisions will rest with Davion on the direction and future of IMC3. Pretty much anything/everything as I understand it is up for debate regardless of anything I may have said before. I'll be making new threads for various topics instead of one big debate.
I2 and Zebedee are protocols that do not use the client/server paradigm
the way I3 and IMC2 do. A distributed network (as I view it. Tyche may
mean something else) would have members joined in a peer-to-peer
arrangement, with no single point of failure. This setup is obviously
terrifying to fascists because it's a surrender of control. If even
allowing channel creation is too wild and crazy, a distributed network
is obviously not worth even discussing.
-Crat
http://lpmuds.net