[Home] [Downloads] [Search] [Help/forum]

Gammon Software Solutions forum

See www.mushclient.com/spam for dealing with forum spam. Please read the MUSHclient FAQ!

[Folder]  Entire forum
-> [Folder]  MUSHclient
. -> [Folder]  Plugins
. . -> [Subject]  trying to make atcp2 plugin to work
Home  |  Users  |  Search  |  FAQ
Username:
Register forum user name
Password:
Forgotten password?

trying to make atcp2 plugin to work

[Reply to this subject]  Reply to this subject   [New subject]  Start a new subject   [Refresh] Refresh page


Pages: 1  2  3  4  5  6 7  8  9  

Posted by Twisol   USA  (2,230 posts)  [Biography] bio
Date Reply #75 on Wed 28 Jul 2010 07:18 AM (UTC)  quote  ]
Message
Because I'd like to keep the cache module from dropping a new parameter into other messages, as Nick's proposal does. Lets say you handle each module with its own callback/subsystem/whatever. I really don't want to add caching support to each one, thank you. Keep it consolidated in the Cache module, refer to each message by an ID which is already part of nearly every message, and keep the other subsystems clean.

'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol
[Go to top] top

Posted by Nick Gammon   Australia  (19,180 posts)  [Biography] bio   Forum Administrator
Date Reply #76 on Wed 28 Jul 2010 07:21 AM (UTC)  quote  ]
Message
Worstje said:

I couldn't help but smile as I read Nick's post just now. By that logic, there would be no issue to a persistent cache to help lower bandwidth across different sessions, but that on the other hand was shot down as being unnecessary.


I'm hoping you agreed with me here. In my many posts I am sure I mentioned that once established, a cached item could survive for ten years. After all, the hash guarantees we are looking at the same data.

Twisol said:

It required that you take action on that incoming message by sending a 'get' with the provided hash, which would then respond with the cached data.


The competing proposal wanted you to request the cached data every session.

- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top

Posted by Twisol   USA  (2,230 posts)  [Biography] bio
Date Reply #77 on Wed 28 Jul 2010 07:23 AM (UTC)  quote  ]
Message
There were three proposals, if I remember. Yours, Worstje's, and mine (which was just a derivative of yours). Mine really just handled how the communication was done. How the data was cached after that was beyond the scope of my particular suggestion.

'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol
[Go to top] top

Posted by Worstje   Netherlands  (867 posts)  [Biography] bio
Date Reply #78 on Wed 28 Jul 2010 07:27 AM (UTC)  quote  ]
Message
My bad, David. You are absolutely right. I'm not finishing my thoughts before expressing them. Nick's proposal did indeed have persistency. Persistency isn't the thing I wanted to laugh about, so.. uh, not sure how I got to write about that.

I meant the lack of support for high-performance caching that would allow caching right in the primary output stream itself, a feature that would be nice to have in a protocol but was not required to be implemented by either client or server. In the end, most data comes through the primary output stream, but nobody was interested in seeing caching as something completely seperate from other protocols like ATCP/GMCP and so forth.

In either case, the idea is to save more bandwidth, which was what Nick spoke about just now, and what got me laughing.

But right... derail. >.>
[Go to top] top

Posted by Worstje   Netherlands  (867 posts)  [Biography] bio
Date Reply #79 on Wed 28 Jul 2010 07:30 AM (UTC)  quote  ]
Message
Nick Gammon said:

Worstje said:

I couldn't help but smile as I read Nick's post just now. By that logic, there would be no issue to a persistent cache to help lower bandwidth across different sessions, but that on the other hand was shot down as being unnecessary.


I'm hoping you agreed with me here. In my many posts I am sure I mentioned that once established, a cached item could survive for ten years. After all, the hash guarantees we are looking at the same data.


I agree with the concept of caching completely.

I disagreed with your implementation, and your lack of interest in the features I put forth in the MDCP+ proposal despite them being very much optional. (I think you called them unnecessary, but it's been a while and I am too lazy to look it up or drag old cows out of the well.)
[Go to top] top

Posted by Nick Gammon   Australia  (19,180 posts)  [Biography] bio   Forum Administrator
Date Reply #80 on Wed 28 Jul 2010 07:34 AM (UTC)  quote  ]
Message
Sorry about that Worstje. After the, ah, robust discussions on the mudstandards forum I concluded that either my proposal was either much too early, or much too late, to be useful. I'm still not sure which.

- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top

Posted by Worstje   Netherlands  (867 posts)  [Biography] bio
Date Reply #81 on Wed 28 Jul 2010 07:41 AM (UTC)  quote  ]
Message
You're forgiven. I never really blamed you in the first place. I gave up on the place myself not too long after.

You worked out your example with plugins and in conjunction with Lasher I believe. I worked it out in a rather wordy and specific RFC that doesn't appeal to people at all. I guess that was my mistake, even though I still hope the right few people will consider it or even implement it, even if it is just the very minimal version, since it is completely independant from other protocols.

So yeah, derail.
[Go to top] top

Posted by Bast   (76 posts)  [Biography] bio
Date Reply #82 on Wed 28 Jul 2010 02:36 PM (UTC)  quote  ]
Message
Wow, I didn't realize the discussion this would start.

I think that you should be able to disable modules. I don't want to receive data that I will never use. Muds pay for every byte they send over the wire.

My use case scenario:

My portable MUSHclient for Aardwolf has a lot of plugins. If a user doesn't want to use one of the plugins, they disable it. Sure, the next time the client starts, those modules will not be requested but the client will be receiving that extra data until that happens. I personally know of several characters who never logout if at all possible. They log channels 24/7. A couple even use MUSHclient for this.

If I don't need the data, then why send it OOB?

Bast

Bast

Scripts: http://bastmush.googlecode.com
[Go to top] top

Posted by Twisol   USA  (2,230 posts)  [Biography] bio
Date Reply #83 on Wed 28 Jul 2010 04:13 PM (UTC)  quote  ]
Message
Bast said:
If I don't need the data, then why send it OOB?


Just to clarify here, the data is actually sent right inside the normal text. The client is expected to strip it out so the user doesn't see it. The Telnet OOB "feature" is not used for this at all.

'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol
[Go to top] top

Posted by David Haley   USA  (3,881 posts)  [Biography] bio   Moderator
Date Reply #84 on Thu 29 Jul 2010 01:21 AM (UTC)  quote  ]
Message
Bast said:
My portable MUSHclient for Aardwolf has a lot of plugins. If a user doesn't want to use one of the plugins, they disable it. Sure, the next time the client starts, those modules will not be requested but the client will be receiving that extra data until that happens. I personally know of several characters who never logout if at all possible. They log channels 24/7. A couple even use MUSHclient for this.

If I don't need the data, then why send it OOB?

So... you're saying that all this work should be done only because people don't want to restart the client once after disabling a plugin because it uses a relatively small amount of extra bandwidth? I'm sorry, but doesn't that sound just a little bit silly? Fine, they want to stay logged in 24/7 once they get running. OK, but is it so unacceptable that the first time they start up and disable some clients, they need to reconnect?

Bast said:
Muds pay for every byte they send over the wire.

Unless you meant this figuratively somehow, hosting packages that charge per byte sent are rather unusual.

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
[Go to top] top

Posted by Twisol   USA  (2,230 posts)  [Biography] bio
Date Reply #85 on Thu 29 Jul 2010 01:28 AM (UTC)  quote  ]
Message
David Haley said:
OK, but is it so unacceptable that the first time they start up and disable some clients, they need to reconnect?


Yes. As I've shown with my quite concrete caching communications, having such a Cache module active changes what the MUD sends from other modules. Being able to say "I'm done with this module" makes it very easy to disable caching. As such, other modules with side-effects are hardly inconceivable.

I've also shown - with code! - how easy it is to refcount the plugins that are using each module. I'd appreciate a concrete example of why you think this is so hard. Waving your hand and mentioning something about race conditions doesn't help either of us.

'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol
[Go to top] top

Posted by Nick Gammon   Australia  (19,180 posts)  [Biography] bio   Forum Administrator
Date Reply #86 on Thu 29 Jul 2010 02:47 AM (UTC)  quote  ]

Amended on Thu 29 Jul 2010 04:48 AM (UTC) by Nick Gammon

Message
Bast said:

If a user doesn't want to use one of the plugins, they disable it.


I think they wouldn't install it if they didn't want it, yes?

I still have to be given a concrete example of a message that:


  • Would be initially sent (eg. by a default client configuration)

  • A lot of players would decide they didn't want

  • Of these players that decide they don't want to use it, they would also not disconnect from the MUD for a very long time (and the MUD doesn't time them out for inactivity)

  • The message itself uses so much bandwidth that disabling the sending of it saves a lot of network usage


What are we talking about here? Inventory? Combat messages? Chat messages? Spell information? Room descriptions?

I am hard pressed to think of a category of message that would fit into those criteria.

Remember, even without some fancy caching system, if you use MCCP, repetitive messages are likely to be compressed away quite significantly.

- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top

Posted by David Haley   USA  (3,881 posts)  [Biography] bio   Moderator
Date Reply #87 on Thu 29 Jul 2010 04:26 AM (UTC)  quote  ]
Message
It's extra, unmotivated work, Twisol. That is what makes it "so hard" -- it's not useful.

Race conditions are easy: some module wants a plugin enabled around the same time another wants it disabled. One message goes through before the other and things get confused as to what the correct state is. Heck, you said yourself: "As such, other modules with side-effects are hardly inconceivable." It is precisely these side effects that you're concocting that make this problem non-trivial. If we adopt your position of basically anything being possible, the problem becomes more and more annoying.

Are these unsurmountable problems? No. Are these problems that nobody has ever solved before? No. Are these problems that would take weeks to solve? No.

But: Are these problems that are actually worth solving? No.

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
[Go to top] top

Posted by Nick Gammon   Australia  (19,180 posts)  [Biography] bio   Forum Administrator
Date Reply #88 on Thu 29 Jul 2010 04:56 AM (UTC)  quote  ]
Message
David Haley said:

Unless you meant this figuratively somehow, hosting packages that charge per byte sent are rather unusual.


I think David is right here. Generally you pay (say) $30 per month and get a cap of how many gigabytes you can use up. They don't charge, like, a cent per megabyte.

- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top

Posted by WillFa   USA  (517 posts)  [Biography] bio
Date Reply #89 on Thu 29 Jul 2010 05:14 AM (UTC)  quote  ]
Message
Can I point out that you guys have been arguing for 2.5 pages about something that should/shouldn't be in the spec, and not how to actually implement the spec or a plugin that conforms to the spec?

Nick, I see why you got disgusted with the mudstandards forum discussion.
[Go to top] top

The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).

To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.


38,296 views.

This is page 6, subject is 9 pages long:  [Previous page]  1  2  3  4  5  6 7  8  9  [Next page]

[Reply to this subject]  Reply to this subject   [New subject]  Start a new subject   [Refresh] Refresh page

Go to topic:           Search the forum


[Go to top] top

[Home]

Written by Nick Gammon - 5K

Comments to: Gammon Software support
[RH click to get RSS URL] Forum RSS feed ( http://www.gammon.com.au/rss/forum.xml )

[Best viewed with any browser - 2K]    [Internet Contents Rating Association (ICRA) - 2K]    [Web site powered by FutureQuest.Net]