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 ➜ Suggestions ➜ A Hide Trigger/Alias/Timer Option and Another group level
A Hide Trigger/Alias/Timer Option and Another group level

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

Pages: 1  2  3 

Posted by Shadowfyr   USA  (1,792 posts)  Bio
Date Reply #30 on Fri 04 Jun 2004 11:26 PM (UTC)
Message
I think I would prefer direct grouping over author. Someone else 'may' use my specifications for instance to desing a plugin that works with ones I made. Obviously in this case, the authors are going to be different, so a named group is imho probably better. As for uniqueness.. This is an issue, definitely. Though a bit less likely than collisions between events imho. Just using a group name like "Kagehi_Combat" would be enough to prevent a collision with "Combat" or "Magnum_Combat", etc.

Though, obviously using just "Combat" is a mistake in the first place. But adjusting one group name near the start of each plugin is a lot easier than fiddling with 50 different event names or tweaking priorities to fix a collection of someone's plugins, if grouping wasn't available. It is a lot easier to fix one simple error in judgement, than have to fix dozens of them (or more in really bad cases). ;)
Top
Posted by David Haley   USA  (3,881 posts)  Bio
Date Reply #31 on Fri 04 Jun 2004 11:29 PM (UTC)
Message
What if I write a plug-in that is an extension to one of your plug-ins? Maybe I would want to be able to catch events even if you initially specified them to be your-group-only.

The best solution seems to be sequencing. Maybe, if one plug-in knew it needs to be ahead of a specific other plug-in (e.g. my extension to yours needs be evaluated first), then it could register itself with MUSHclient as being before. Then you simply give the user the power to manually modify sequencing numbers, and the problems seem to be solved.

Basically I have the impression that Shadowfyr's problem with a true/false intercepting event handler is that he's paranoid that somebody will gobble events they shouldn't. :-) In that case I would suggest that you simply modify the plug-in... or, Nick, you can create an option where you can disable a plug-in's ability to halt or even process events.
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
Top
Posted by Shadowfyr   USA  (1,792 posts)  Bio
Date Reply #32 on Sat 05 Jun 2004 12:10 AM (UTC)
Message
Quote:
What if I write a plug-in that is an extension to one of your plug-ins? Maybe I would want to be able to catch events even if you initially specified them to be your-group-only.


Umm. Make yours load as part of my group? Duh! lol

And there is nothing preventing me from creating global events that I expect to be captured by 'all' plugins, not just those in my own group, as well as events you can send that mine know how to handle. I however probably don't want yours to have the option to completely override mine, even if you placed it in the same group. In which case, all you have to do is tweak maybe one plugin in my set to make yours have higher priority, not all half dozen or more I may have. As for any plugin knowing that it 'needs' to be ahead of others, that is likely only the case if it 'knows' what plugins it will be working with in the first place, in which case, why not have those in a group anyway?

I still don't get what your complaint is Ksilyan. ;)
Top
Posted by David Haley   USA  (3,881 posts)  Bio
Date Reply #33 on Sat 05 Jun 2004 12:15 AM (UTC)
Message
My complaint is that you're saying features are stupid simply because you don't want them, even though other people may have a use for them.

Quote:
Umm. Make yours load as part of my group? Duh! lol

What if my plugin needs to also be in my group so that it can see my specific events as well as yours? "Duh! lol" yourself.
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
Top
Posted by Shadowfyr   USA  (1,792 posts)  Bio
Date Reply #34 on Sat 05 Jun 2004 01:22 AM (UTC)
Message
I am not saying they are stupid, so much as impractical to impliment. And unless your plugin for some reason needs to halt some process that mine performs, why wouldn't the global, but non-interruptable events work to have them talk to each other?

How about this for a solution:

FireEvent(<type>, <data>)
Responder: Sub GlobalEvent(<ID>, <type>, <data>)

boolean = FireGroupEvent (<group>, <type>, <data>)
Responder: Function GroupEvent(<ID>, <type>, <data>)

That way you can talk direct to another group, as though it was your own. You need yours to be informed of stuff mine is doing? Just add an extra line for that event to send to your group as well.

I can't really think of any case where I would even want someone else plugin to intercept and make my own plugins ignore their own events. It defeats the whole purpose of isolating them to prevent that in the first place. And if you really need it to do that, then you could always edit the plugins themselves to respond to an 'ignore this event' message of some sort. I can't see any practical way to have it both ways, allowing your plugins to interfer with the operation of mine (instead of just communicating) *and* also maintain the isolation needed to provide a level of safety between collections of them.
Top
Posted by David Haley   USA  (3,881 posts)  Bio
Date Reply #35 on Sat 05 Jun 2004 01:42 AM (UTC)
Message
Quote:
And unless your plugin for some reason needs to halt some process that mine performs, why wouldn't the global, but non-interruptable events work to have them talk to each other?

The 'and unless' part of your sentence answers the question. :-)

I sort of think you're being paranoid about security here. On Windows, when you install stuff, you're trusting that the software isn't going to do some really weird event hooking. The newer OSes fix this to some degree with better user security, but it still comes down to the simple fact that if things aren't done right, they crash.

Perhaps at the moment you might not want somebody messing with your plugin... otherwise, you probably would have made the feature to do whatever they want.

That being said, how many times have you and others complained about things in MUSHclient's event loop that you would have wanted? Nick at the time didn't feel they were necessary and so didn't expose the necessary interfaces. He may still not think they're necessary, but that's beside the point. What is relevant is that closing down your design like you're doing is somewhat of "selfish design" in that it prevents anybody in the future from talking with your script other than the - very possibly quite limited - interface you have created.

Let's say you have a plug-in that reacts to tells and changes their color and doesn't log them. Nothing more. I'm making it trivial on purpose for simplicity of example. Now let's say that I want to use your plug-in (on the assumption it does something else that's useful) but I want to prevent it from acting when the tell comes from Fred. So, assuming there is a 'tell' event (which there isn't, but whatever) I would intercept the tell event, and if it comes from Fred I'll kill it and deal with it myself; otherwise I will pass it on so that yours will deal with it.

I haven't spent the time to think up an exact and specific need for this in MUSHclient, but, this same event process has been used elsewhere and for a reason. I have the impression that you are saying we shouldn't have it in MUSHclient not because there's a *problem* with it, but simply because you don't see a use at the moment.

In the end the user has choice over what plug-ins are installed. If someone writes a plug-in that 'misbehaves', then the user simply shouldn't be using it or should complain to the plug-in author, not to the *event system* author.
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
Top
Posted by Shadowfyr   USA  (1,792 posts)  Bio
Date Reply #36 on Sat 05 Jun 2004 02:20 AM (UTC)
Message
Sigh.. Fine.. I would prefer something more stable and less "gee, lets hope things really do happen when they need to". Maybe, something like you suggested. In case where you 'absolutely must' have it, you could do:

ListenToEvents <group>

So events fired by that group would also be seen and reacted to by your own plugins GroupEvent function. You would have to intentionally bypass the security provided to seperate them that way, but as long as your own group had a sequence lower than mine, your plugin would recieve and process the event first. But I don't think the benefit of having every plugin global and interruptable is really as important as minimizing the problems that such a totally open system creates, with everything from general event collisions to actually making sure the right plugins execute in the right order.
Top
Posted by Nick Gammon   Australia  (23,173 posts)  Bio   Forum Administrator
Date Reply #37 on Sat 05 Jun 2004 11:13 PM (UTC)
Message
Quote:

How about this for a solution:

FireEvent(<type>, <data>)
Responder: Sub GlobalEvent(<ID>, <type>, <data>)


OK, yes this sounds quite practical.

Assuming that the event cannot be cancelled then you *know* your other plugins, if installed, will get it. Also the ID (the ID of the sending plugin) will be supplied by MUSHclient, and thus cannot be spoofed.

So, your event handler might look like this:


Sub OnPluginEvent (id, type, data)

If id = "4aa4239d9a3d479fa6559ef5" Or _ 
   id = "df84905195b4526b510d2fa5" Then

'  process event

End If

End Sub


By testing for the IDs of your known plugins, you eliminate events (possibly with the same names) which are sent by unknown plugins.

The only possible downside is that the other plugins (ones you didn't write) might react in an unexpected way to your event, but hopefully that won't occur. If you are really worried about it you simply use CallPlugin to call them directly, and not use events.

As for groups, what is really achieved there? Someone can always claim to be in your group when they are not.

BTW, you can use the "Arrayxxxx" functions to pass multiple arguments by name, like this:


ArrayCreate "args"
ArrayClear  "args
ArraySet    "args", "name", "Shadowfyr"
ArraySet    "args", "language", "C++"
ArraySet    "args", "client", "mushclient"

FireEvent "foo", ArrayExport ("args", ",")


This passes the three arguments (name, language, client) to the event handler. It then extracts them like this:


Sub OnPluginEvent (id, type, data)
dim name, language, client

'  extract args

  ArrayCreate "args"
  ArrayClear  "args
  ArrayImport "args", "data", ","

  If type = "foo" Then
    name     = ArrayGet ("args", "name")
    language = ArrayGet ("args", "language")   
    client   = ArrayGet ("args", "client")   

  '  process args here

  End If  ' end of event foo

End Sub

- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Shadowfyr   USA  (1,792 posts)  Bio
Date Reply #38 on Sun 06 Jun 2004 01:33 AM (UTC)
Message
Well. The grouping was mainly a way to make sure that plugins really do execute, if only without your own group, in a known order. True, this may be the case with using the ID to make sure as well, but I was looking for a system that didn't explicitly need the related plugins to know what the ID's where, while still providing a similar level of protection. Frankly, I thought of passing the ID, not as a way to verify which plugins where valid, but to let them find out information about each other that you can't get without that, like which group they might have been in.

However, you have a point. As much as I dislike having to set the ID of each plugin that is valid, to avoid such collisions, it does provide some of the same degree of seperation and there isn't any reason why someone can't set up their plugin to accept an event that registers the sender as an exceptable source as well.

The only thing grouping would thus do then is allow you to disable several related plugins at once, but someone developing one could make that an event in them anyway.

So, we still need to be able to set 'sequence' or execution order, but anyway you try to manage that, someone can still mess it up anyway. ;) Managing such per plugin isn't that much worse than setting it once for a collection, then managing the groups order instead. Groups are probably not really necessary for anything, even mass disabling, which could be done through all the IDs the plugin doing the disabling knows. In fact, it is probably better, since it can disable the plugins it wants to, but not itself.

Ksilyan ought to be real unhappy about this though. ;) His whole arguement is that he might want to talk to my plugin, even though my plugin restricts what calls it will accept from him. Using the ID like this is even better at preventing such interference than groups. lol

----

BTW, as to the other type of events (objects), I am looking around now for info on IProvideClassInfo2. Apparently, it may be possible to have Mushclient get the IDispatch for the object, then pass the script the IProvideClassInfo2, which could, at least in theory, allow the scripts to use GetRef or the like to register an event handler for the object. This means COM events can be handled by the scripts, where currently you have to more or less create a wrapper for the control that can use CallPlugin or the like to 'inform' the script of what happened. This is impractical in the extreme. If there is some way to effectively register the object for proper use by the scripts own event manager, it solves the problem completely.
Top
Posted by David Haley   USA  (3,881 posts)  Bio
Date Reply #39 on Sun 06 Jun 2004 06:52 AM (UTC)
Message
Quote:
Ksilyan ought to be real unhappy about this though. ;) His whole arguement is that he might want to talk to my plugin, even though my plugin restricts what calls it will accept from him.


Actually... no. My argument was that I may wish to restrict your plugin's access to events, to be able to intercept/modify events, not necessarily talk to them. Regardless my main gripe was just that you seemed to be demanding specs that met your requirements and only yours. :)
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
Top
Posted by Shadowfyr   USA  (1,792 posts)  Bio
Date Reply #40 on Sun 06 Jun 2004 09:17 PM (UTC)
Message
Well, since the only reason I initially suggested grouping was to provide reliable priorities and everything else stemmed from arguements over the limitations of that, I figured something that could simplify plugin management might be a solution. I can't help it if we both have the tenacity of a bulldog when arguing our views. ;)
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.

140,728 views.

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

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