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 ➜ ATCP plugin for Achaea
ATCP plugin for Achaea

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

Pages: 1  2 3  4  

Posted by Twisol   USA  (2,257 posts)  Bio
Date Reply #15 on Tue 09 Mar 2010 11:08 PM (UTC)
Message
At some point, I'd like to be able to come to an agreement or compromise over the ATCP plugin, because I believe that there should be only one generally available. I'll be uploading all of my plugins to my own repository on GitHub shortly, including my ATCP plugin, so it should be easier to compare and discuss.
'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol
Top
Posted by Nick Gammon   Australia  (23,133 posts)  Bio   Forum Administrator
Date Reply #16 on Wed 10 Mar 2010 04:46 AM (UTC)
Message
I'm all for agreement. ;)

It seems to me after testing your newer version that they don't clash as much as you are no longer stripping out the telnet negotiation from the raw packets. We still have the issue of multiple "hello" messages however.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Twisol   USA  (2,257 posts)  Bio
Date Reply #17 on Wed 10 Mar 2010 05:47 AM (UTC)
Message
Nick Gammon said:

I'm all for agreement. ;)

It seems to me after testing your newer version that they don't clash as much as you are no longer stripping out the telnet negotiation from the raw packets. We still have the issue of multiple "hello" messages however.


That's a protocol issue, though. The protocol itself states that the hello must be the first ATCP message sent by the client (besides enabling ATCP in the first place), so unless we have a way to unify outgoing 'hello' messages in a usable manner, it's not something you can easily do. Obviously it would be best if every plugin that used ATCP could stand on its own, but the client itself would need to provide an interface specifically for ATCP to make that feasible.


At that point, you have only two real options:

1. Standardize a single ATCP plugin and make it easily available. This is my preferred choice.

2. Incorporate full ATCP support into the client itself. I dislike this; it's more of a gut feeling than anything, but once we have ATCP, why not ZMP or some other arcane protocol? ATCP is only used in IRE games, remember. And even if we do decide to do this, the API needs to be consistent, clean, and useful. To quote someone in a book I've been reading, we have to have the empathy gene. How will it be used? Does it make sense? This is something I'd rather not decide in a hurry, this should be fleshed out.


So far we're doing fine with ATCP as a plugin, so 2 is more work for little gain in the end. And we can always, always refine a plugin, much more easily than a core client interface. I'm also a big fan of doing as much as possible with client extensions; I think a lot about MUSHclient would be better off as a plugin, like the Convert Clipboard Forum Codes utility and the activity toolbar.
'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol
Top
Posted by Nick Gammon   Australia  (23,133 posts)  Bio   Forum Administrator
Date Reply #18 on Wed 10 Mar 2010 05:58 AM (UTC)
Message
Twisol said:

The protocol itself states that the hello must be the first ATCP message sent by the client (besides enabling ATCP in the first place), so unless we have a way to unify outgoing 'hello' messages in a usable manner, it's not something you can easily do.


If you can find something that documents the protocol that much you are doing better than I am.

In any case, since this is the sticking point, I have written to the Achaea admins suggesting that this requirement could be relaxed. What real purpose does it serve? Basically you are just asking the server to enable certain messages. Why does this all have to be done at once?
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Twisol   USA  (2,257 posts)  Bio
Date Reply #19 on Wed 10 Mar 2010 06:02 AM (UTC)
Message
Good question. I'll admit I tend to stay away from pestering them, mainly because I don't have the kind of clout required to make it not sound like whining. If there was a way to simply enable/disable messages at any given time, and simply start out as "ATCP enabled, all modules disabled", that would certainly help a lot.

On the other hand, I do know that modifications to Rapture (the MUD engine they use) have to go through more red tape than modifications to the code of a single game. I can't recall who said that specifically - maybe Kunin, the Tears of Polaris producer? - but I suspect that ATCP is a core part of Rapture.
'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol
Top
Posted by Twisol   USA  (2,257 posts)  Bio
Date Reply #20 on Wed 10 Mar 2010 06:03 AM (UTC)

Amended on Wed 10 Mar 2010 06:05 AM (UTC) by Twisol

Message
Nick Gammon said:

Twisol said:

The protocol itself states that the hello must be the first ATCP message sent by the client (besides enabling ATCP in the first place), so unless we have a way to unify outgoing 'hello' messages in a usable manner, it's not something you can easily do.


If you can find something that documents the protocol that much you are doing better than I am.


http://www.ironrealms.com/nexus/atcp.html
ATCP Documentation said:

To facilitate the flexible messaging protocol, we define a single message that is "outside" the module system and is provided to allow the client to tell the server about what modules it supports. This should be the very first message the client sends. (Note: currently there is no way to tell the -client- what features the server does, but this could easily be added by simply filtering the list and providing the last step in the negotiation.)

It goes on to explain exactly how the 'hello' message is structured. I've known about this page for a long time, though, no worries. It took a lot of Googling to actually dig it up in the first place.

It's a bit out of date when it comes to the most recent messages, like Client.Map and Room.Num, though. It would be nice if they could release a more up-to-date revision, and in fact that's one of the things I did ask them about. Never really heard back about it though.
'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol
Top
Posted by Twisol   USA  (2,257 posts)  Bio
Date Reply #21 on Wed 10 Mar 2010 06:27 AM (UTC)
Message
I've uploaded all of my ATCP-based plugins to GitHub, including my current ATCP plugin. They all follow the "structured plugin" paradigm, which allows them to keep close the libraries and resources they need. The main advantage is that the PPI library that my ATCP plugin uses to communicate with the other plugins doesn't have to be downloaded separately, since it's included with each plugin.

http://github.com/Twisol/MUSHclient-plugins
'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol
Top
Posted by Nick Gammon   Australia  (23,133 posts)  Bio   Forum Administrator
Date Reply #22 on Wed 10 Mar 2010 07:15 PM (UTC)
Message
This is what troubles me ...

My experience bar plugin is 151 lines, and the ATCP plugin I wrote is 204 lines. The ATCP plugin can be shared between the experience bar, the health bar and the mapper.


You want me to replace the ATCP plugin with a downloaded zip file which contains 8 files and 4 folders. The files are:


  • plugin.xml - 20 lines

  • aliases.lua - 9 lines (seems to be for debugging)

  • plugger.xml - 47 lines

  • ppi.lua - 390 lines

  • reflex.lua - 321 lines

  • main.lua - 240 lines

  • parser.lua - 174 lines


Total for getting ATCP functionality: 1,201 lines.

Then I have to work out how it all works. And I gather with the PPI stuff I then have to "register" the desire to receive messages (my method just uses BroadcastPlugin).

Your system may be great for a more complex environment, but I want to be able to just get up a health bar or experience bar without all this fiddling around. And have the files available right here (or on GitHub which I control).


Twisol said:

Also because, as I mentioned in another thread, ATCP requires a hello message listing the modules you want to activate. You can only send one 'hello' message, and this one 'hello' needs to know all of the modules that are to be used.


Actually after discussing with their programmer, you can send more than one, and it respects the *last* one - I think you gave the impression before that only the first one counted. I explained about the multiple plugin problem and they are happy to remove that restriction, and allow the "hello" messages to be cumulative.

The whole thing about "if you install my plugin, then your plugin won't work" goes against the grain of the design of plugins (http://www.gammon.com.au/plugins/) where they are supposed to be "self-contained" things that don't require a lot of cross-plugin functionality to work.

I admit I have moved the ATCP functionality to a second plugin myself, but it is designed in such a way that it should not interfere with other plugins - apart from the IRE problem with only one "hello" message which I only heard about this week, and am on the way to solving.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by David Haley   USA  (3,881 posts)  Bio
Date Reply #23 on Wed 10 Mar 2010 08:22 PM (UTC)
Message
Nick Gammon said:
Total for getting ATCP functionality: 1,201 lines.

Then I have to work out how it all works. And I gather with the PPI stuff I then have to "register" the desire to receive messages (my method just uses BroadcastPlugin).

Your system may be great for a more complex environment, but I want to be able to just get up a health bar or experience bar without all this fiddling around. And have the files available right here (or on GitHub which I control).

I have to say that I disagree with your reasoning here. I don't know anything about Twisol's implementation so my comment is not a statement regarding his work. That said, your reasoning is essentially saying that special purpose libraries are always the correct solution. Yes, if you just want a health bar and some stuff like that, maybe something small is appropriate. But eventually people will want more (or they already do want more) and it rapidly becomes unmanageable to have a bunch of special-purpose components all trying to do the same thing.

Now, again to be clear, I'm not arguing for or against Twisol's implementation (I don't know anything about it). I'm arguing against using lines of code and exact specific applicability alone as metrics, because it seems very clear to me that when designing a general-purpose library, you need to be, well, more general.
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
Top
Posted by Twisol   USA  (2,257 posts)  Bio
Date Reply #24 on Wed 10 Mar 2010 09:55 PM (UTC)

Amended on Wed 10 Mar 2010 09:57 PM (UTC) by Twisol

Message
Nick Gammon said:

This is what troubles me ...

My experience bar plugin is 151 lines, and the ATCP plugin I wrote is 204 lines. The ATCP plugin can be shared between the experience bar, the health bar and the mapper.

You want me to replace the ATCP plugin with a downloaded zip file which contains 8 files and 4 folders. The files are:

[...]

Total for getting ATCP functionality: 1,201 lines.

Line count is an absolutely awful way to go about it. I value structure above and beyond mere brevity. You also list parser.lua, which I removed in this last release.

(EDIT: Also note that the majority of my plugin is dedicated to the PPI-based interface, which is mere fluff on the core functionality. The PPI-based interface makes it a lot easier (and perhaps even more fun) to work with ATCP.)

Nick Gammon said:
Then I have to work out how it all works. And I gather with the PPI stuff I then have to "register" the desire to receive messages (my method just uses BroadcastPlugin).

I admit I haven't gotten my documentation up to scratch yet, but I always point to roomname.plugin as an example of how to use the interface. You do have to register for specific messages, but it's no different from, say, registering event handlers with Javascript. (That might be a bad example, I don't know, but it's not an uncommon technique)

Nick Gammon said:
Your system may be great for a more complex environment, but I want to be able to just get up a health bar or experience bar without all this fiddling around. And have the files available right here (or on GitHub which I control).

What fiddling around? I think setting up your own ATCP interface is more work than adding another plugin and using an API that's already been shown to work in general. I think the biggest issue is understanding the "structured plugin" format. You're right: it's a zip file. It's structured internally to allow for easily breaking up your own plugin into manageable components, and bundling resources and third-party libraries to make it a single unit. (Just like compiling sqlite3, zlib, png, etc. into .libs and linking them statically into the MUSHclient executable.) It takes a little getting used to on the development side, but it maintains the one-download aspect of normal XML plugins while making it way easier on the developer to include and manage other files required for the plugin to work.


Nick Gammon said:
Actually after discussing with their programmer, you can send more than one, and it respects the *last* one - I think you gave the impression before that only the first one counted.

I admit the details are fuzzy - the server's treatment of 'hello' isn't explained in the spec - but in the end it's the same: you have to unify the 'hello' messages in the end, or all the previous ones won't count.

Nick Gammon said:
I explained about the multiple plugin problem and they are happy to remove that restriction, and allow the "hello" messages to be cumulative.

Whether the unification occurs client-side or server-side doesn't matter, so I'm very happy about this. Assuming I can send multiple 'hello's, and each one can enable new modules ones while maintaining the status of the previous ones, that's fantastic. A way to -disable- messages would be great too, but...

Nick Gammon said:
The whole thing about "if you install my plugin, then your plugin won't work" goes against the grain of the design of plugins (http://www.gammon.com.au/plugins/) where they are supposed to be "self-contained" things that don't require a lot of cross-plugin functionality to work.

This plugin has existed in various forms for a long time. It was a very iterative development, and before the changes to telnet subnegotiations in MUSHclient, some of them leaked through (as I mentioned with Char.Vitals). It was essential to strip the ATCP data out to guarantee that the data wouldn't show up on-screen. Nowadays you've fixed that particular issue.

On a note of personal ideology, I think you're being a little narrow-minded about plugins. What you envisioned plugins to be doesn't matter, it's how plugins are actually used that matters. (Look at the many uses of WD-40 for a good analogy.) Obviously, plugins that are standalone tend to be better, because it's a single download to get it working. But that's no reason to say that they can't or shouldn't work closely with other plugins, because you can do some really cool things that way.

Nick Gammon said:
I admit I have moved the ATCP functionality to a second plugin myself, but it is designed in such a way that it should not interfere with other plugins - apart from the IRE problem with only one "hello" message which I only heard about this week, and am on the way to solving.

Again, my ATCP plugin was developed iteratively over a long, long period, and I'm only the most recent of its maintainers. I'm very glad that I can now remove (and have removed) the blocking behavior of the ATCP data. Once the 'hello' message has been solved, the ATCP plugin very well may not be needed anymore... though I'd still be glad to maintain an auxiliary library for ATCP to make it easier, that you can stick in a structured plugin. ;)
'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol
Top
Posted by Nick Gammon   Australia  (23,133 posts)  Bio   Forum Administrator
Date Reply #25 on Wed 10 Mar 2010 10:10 PM (UTC)

Amended on Wed 10 Mar 2010 10:14 PM (UTC) by Nick Gammon

Message
(in response to David Haley):

What I am saying is, it seems too much. Basically I am trying to match certain sequences that comes down from the MUD, like a trigger. Now you don't install 1200 lines of code to match a prompt do you?

Really, the code needed to pull out room numbers is as simple as this:


-- agree to use ATCP
function OnPluginTelnetRequest (type, data)
  if type == 200 and data == "WILL" then
    return true
  end -- if
end -- function OnPluginTelnetRequest

function OnPluginTelnetSubnegotiation (type, option)

  if type ~= 200 then
    return
  end -- not Achaea subnegotiation

  local command, args = string.match (option, "^([%a.]+)%s+(.*)$")
  
  if command == "Room.Num" then
    handle_room_number (args)
  end -- if
          
end -- function OnPluginTelnetSubnegotiation


I don't really see why that couldn't even be in every plugin, it's not as if the protocol is going to change every 5 minutes.

This reminds me of the time I wanted to do something simple, like break up a URL into its component parts (http, the domain, the directories and the file, that sort of thing).

Now I read somewhere that the Boost library did that stuff, and in the interests of not "reinventing the wheel" I looked for it, and downloaded it (it was PHP code I think).

Then when I tried to run it I was told I needed to get ZEND as well, so quite a few megabytes later I had installed ZEND. Then when I tried to run it I was told I needed some "dependency" libraries, so quite a few more megabytes later I had downloaded and installed those. Then each of those libraries had more dependencies, and there was more downloading.

So after about an hour, and about 100 megabytes later, it still wasn't working and I called a halt to it. In my brain I thought, "this 'little library' is bigger than my entire application!".

It would have been quicker, and easier, and I would have understood what I was doing, if I just wrote my own regexp that broke up the URL. So that is what I did. I reinvented the wheel.

It's a similar thing with stuff like Python - to distribute Python with MUSHclient would more than double the size of the distribution. So the "little script engine" is bigger than the application it is installed in. Lua, however, is not.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Twisol   USA  (2,257 posts)  Bio
Date Reply #26 on Wed 10 Mar 2010 10:24 PM (UTC)

Amended on Wed 10 Mar 2010 10:25 PM (UTC) by Twisol

Message
(I only spotted the "in response to David Haley" after I wrote most of this, so I figured I might as well post it anyways. Grain of salt.)

Well, yes. It's a juggling contest. That whole way-overdone dependency tree is one of the things my structured plugin design is intended to solve. You can include the libraries you want with the plugin that needs it (unless it's provided by MUSHclient natively, obviously). ATCP uses three libraries:

1. Plugger, a stub library which makes it easier to write a structured plugin by "fixing" the Lua paths to be relative to your plugin's folder instead of the MUSHclient plugins/ folder. It also automatically executes scripts/main.lua, creating a divide between plugin metadata (the .xml) and implementation (whatever other .lua files you have).

2. Reflex, which provides a natural Lua-oriented interface to triggers, aliases, and timers. It's an alternative to the XML format, and being something of a purist in that respect, I opted to use Reflex to implement my debug alias. You mentioned perhaps including it with MUSHclient at some point, which would mean ATCP (and everything else, really) wouldn't have to include their own copy.

3. PPI (my version), to facilitate easier and more natural communication between plugins. Specifically, it lets other plugins register callbacks to specific messages, which makes it more modular and neater.

Dependency hell? No, because they're included explicitly in the plugins that need them. What would be four downloads to get a working ATCP plugin - three if you want to drop Reflex - is taken down to one in an easy, simply-unzip package.


(EDIT: To the code snippet you posted:) In theory, I agree with you that it should be that simple. But one important point is that many Achaeans use the Vadi system, which is a proxy you connect to on your computer. At the time of this writing, it sends its own 'hello' message and doesn't pass your own through, and it misbehaves if you do try to send one. So I have an extra check in my OnPluginTelnetRequest to -not- send a 'hello' message if we're connected to 127.0.0.1. And that's something the general developer could easily forget, although then it would be their fault and not mine.
'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol
Top
Posted by David Haley   USA  (3,881 posts)  Bio
Date Reply #27 on Thu 11 Mar 2010 05:26 AM (UTC)
Message
I guess the issue is that Twisol's ATCP handler is meant to operate in a framework, and that framework requires some other stuff. Is the framework is always necessary? Well, probably not. Does that mean it's not useful? I don't think you could say that either.

Basically if the argument is merely "look, mine is smaller" I don't think that suffices. It would have to be an awful lot smaller to justify discarding a framework for writing more plugins.

Interesting questions here might be to what extent the ATCP stuff actually needs the rest of the stuff (like PPI) and whether or not the ATCP core could be isolated, and the framework integration provided separately.

FWIW I disagree that that code should be repeated in every plugin, even if yes the protocol won't be changing every five minutes. Repeating code like that is simply a bad idea. What if the protocol does eventually change? All of a sudden you need to update every single plugin that uses that functionality. This seems to me to be a fairly obviously inferior situation to having a slight overhead the first time you install a plugin.

I agree that often it feels like too much when you just want a simple thing; Xerces felt like this for me for XML parsing. "I just want an XML tree..." But comparing this to Xerces or Zend or PHP seems like a little bit of a stretch to me.
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
Top
Posted by Twisol   USA  (2,257 posts)  Bio
Date Reply #28 on Thu 11 Mar 2010 05:39 AM (UTC)

Amended on Thu 11 Mar 2010 05:40 AM (UTC) by Twisol

Message
David Haley said:
Interesting questions here might be to what extent the ATCP stuff actually needs the rest of the stuff (like PPI) and whether or not the ATCP core could be isolated, and the framework integration provided separately.


Mmm... I could remove Reflex if I wanted, since it only powers one minor debugging alias. I could also remove Plugger if I wanted, but I like to use it because it helps enforce the plugin's structured-ness, and it's so few lines anyways.

PPI is how the data actually gets sent around, and it's integral to the registered-callbacks facility. That's not so much a framework as simply a way to easily get at the data. I've gone the BroadcastPlugin route before - that's how it originally was - and it was ugly, and it was very hard for the client to tell the ATCP plugin to enable a module or to get a specific message or whatnot in a clean manner.

EDIT: I'm not sure what context you're using "framework" in, now that I think about it. Are you referring to my "structured plugin" format, or the ATCP functionality itself?
'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol
Top
Posted by Larkin   (278 posts)  Bio
Date Reply #29 on Thu 11 Mar 2010 11:37 AM (UTC)
Message
I agree with Nick on two things here: these two plugins are different takes on the same thing and can co-exist peacefully, and the simple solution is often the preferred solution.

The PPI code is a means of passing data back and forth between plugins, which I find largely unnecessary. I steer away from plugins as much as possible in my own coding, preferring to have everything in the same shared space. Things like this feel too much like COM to me, and those of us who've dealt with COM programming know the pain it can cause.
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.

131,242 views.

This is page 2, subject is 4 pages long:  [Previous page]  1  2 3  4  [Next page]

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

Go to topic:           Search the forum

[Go to top] top

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

Home