Register forum user name Search FAQ

Gammon Forum

Notice: Any messages purporting to come from this site telling you that your password has expired, or that you need to verify your details, confirm your email, resolve issues, making threats, or asking for money, are spam. We do not email users with any such messages. If you have lost your password you can obtain a new one by using the password reset link.

Due to spam on this forum, all posts now need moderator approval.

Entire forum ➜ MUSHclient ➜ Plugins ➜ trying to make atcp2 plugin to work

trying to make atcp2 plugin to work

It is now over 60 days since the last post. This thread is closed. Refresh page

Pages: 1 2 3 4 5 6 7 8 9

Posted by

Twisol USA (2,257 posts) Bio

Date

Reply #75 on Wed 28 Jul 2010 07:18 AM (UTC)

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

Posted by

Nick Gammon Australia (23,133 posts) Bio Forum Administrator

Date

Reply #76 on Wed 28 Jul 2010 07:21 AM (UTC)

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

Posted by

Twisol USA (2,257 posts) Bio

Date

Reply #77 on Wed 28 Jul 2010 07:23 AM (UTC)

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

Posted by

Worstje Netherlands (899 posts) Bio

Date

Reply #78 on Wed 28 Jul 2010 07:27 AM (UTC)

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. >.>

Posted by

Worstje Netherlands (899 posts) Bio

Date

Reply #79 on Wed 28 Jul 2010 07:30 AM (UTC)

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.)

Posted by

Nick Gammon Australia (23,133 posts) Bio Forum Administrator

Date

Reply #80 on Wed 28 Jul 2010 07:34 AM (UTC)

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

Posted by

Worstje Netherlands (899 posts) Bio

Date

Reply #81 on Wed 28 Jul 2010 07:41 AM (UTC)

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.

Posted by

Bast (78 posts) Bio

Date

Reply #82 on Wed 28 Jul 2010 02:36 PM (UTC)

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://github.com/endavis

Posted by

Twisol USA (2,257 posts) Bio

Date

Reply #83 on Wed 28 Jul 2010 04:13 PM (UTC)

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

Posted by

David Haley USA (3,881 posts) Bio

Date

Reply #84 on Thu 29 Jul 2010 01:21 AM (UTC)

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

Posted by

Twisol USA (2,257 posts) Bio

Date

Reply #85 on Thu 29 Jul 2010 01:28 AM (UTC)

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

Posted by

Nick Gammon Australia (23,133 posts) Bio Forum Administrator

Date

Reply #86 on Thu 29 Jul 2010 02:47 AM (UTC)

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

Posted by

David Haley USA (3,881 posts) Bio

Date

Reply #87 on Thu 29 Jul 2010 04:26 AM (UTC)

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

Posted by

Nick Gammon Australia (23,133 posts) Bio Forum Administrator

Date

Reply #88 on Thu 29 Jul 2010 04:56 AM (UTC)

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

Posted by

WillFa USA (525 posts) Bio

Date

Reply #89 on Thu 29 Jul 2010 05:14 AM (UTC)

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.

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.

305,988 views.

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

It is now over 60 days since the last post. This thread is closed. Refresh page

Go to topic: Search the forum

Information and images on this site are licensed under the Creative Commons Attribution 3.0 Australia License unless stated otherwise.