Our records show that you have outstanding author rewards points. Please confirm your latest payment information and redeem your points balance via the Author Reward Store.
If you have a haystack and a needle, and the job is to optimize the whole thing, do you optimize the haystack or the needle. This is a needle optimization. It's broadly speaking a waste of time, because any optimization is sqashed by the size of the haystack already.
The analogy is horrible. We're not looking for a needle in a haystack. We found a needle. Might as well remove it from the haystack. Your argument is essentially: Ohh look I found a needle in a haystack but it's such a small thing and unlikely that anyone would ever step on the needle so I'll just throw it back in.
Sure one could ditch the version (depending how you do this this may or may not break compatibility) and then reintroduce it - as you said - to reestablish compatibility (when we maybe just broke it) at the next protocol upgrade. Not sure why you don't appreciate the silliness of the exercise.
The proper way to handle this from the start was to always include the ability to respond to a version request in the lib. Then have the requests that are only being used to print stuff on demand request and callback to do it.
If you ever needed for protocol reasons to always know the version THEN add announce/request sending on party join.
There is absolutely no protocol consistency purpose to having an announce/request on login to your entire guild. Because outside of the version information it never bothers to talk to the guild it always talks to the group.
I can see the value in having a way to do the request for the guild for version checking purposes without bothering having to get your guild members in a group.
But that functionality has absolutely nothing to do with protocol consistency.
So in reality I think the code would be simpler if the callback request method was used and the only if absolutely necessary due to protocol changes would you need the request/announce message. If you need it you could indeed move back to something similar to what you have. But if you didn't then you'd avoid overhead for something that you may never use.
The GUID stuff wouldn't even be being talked about if Shadowed hadn't brought this issue up. So when Shadowed pointed out the version information was a waste of resources he was doing so based upon the current stable state of LHC-3.0 not having needed a protocol change ever.
If the GUID stuff actually gets bolted on then I suppose you could leave stuff in place. But I don't see the point in bolting it on without a major bump since you'll end up sending double messages for the time being.
You could use the versioning to decide if you could avoid sending the old messages but if only a single old lib is present you'd have to send the old messages. I'd think a major bump including the removal of the old messages would encourage a faster upgrade across the board and would keep traffic to a minimum.
At the same point you could adopt the strategy for avoiding the request/announce traffic until you need it. If it was needed then so be it. But might as well avoid it as long as we could.
If the GUID stuff actually gets bolted on then I suppose you could leave stuff in place. But I don't see the point in bolting it on without a major bump since you'll end up sending double messages for the time being.
I'll take that as agreement. Thanks. Let's leave the stuff in place given that a protocol change is happening.
Look ultimately our disagreement is simple. You want folks to spend attention to micro-manage really minor stuff ignoring other aspect. I want you to consider other aspects and get the focus of the silly micromanagement. I don't think we'll have an actual agreement ever over this.
Really there is hardly any ground for action here on the protocol side. Take the guild sync out (if it has no extra purpose), and move on to more interesting things.
Because the traffic (and more important, the resulting processing) is infinitesmal, the protocol was designed to be flexible/extensible by using pre-comm version exchange, simply because the penalty was so small, it would be stupid not to do it, even if no immediate use could be seen back then. This was in foresight of the unexpected. Now, LHC has been here for a while and still doesn't use it. It's easy to point fingers now and call it a failure. I don't view it that way. This version information plays a key role in the upgrades to the protocol that are going to happen now. There's a difference between protocol design and implementation. Just because one implementation of a protocol does not make use of some information provided in certain primitives, it does not mean the protocol is wrong. The implementation has a set of properties and the protocol has a set of properties. One property of the protocol used by LHC is that it has pre-comm version exchange. The protocol was designed that way, deliberately. The implementation of LHC does not utilise this property currently, but it obeys the protocol, meaning that when LHC starts using it, the information will be there. Protocol conformance cannot be retroactively fitted to already distributed implementations, so it is crucial that implementations conform to the protocol even if they don't use some of the information provided.
If the protocol version exchange was designed to be request only, it would never be possible to adjust communication in response to the actual listerners, because the actual listerners can change any given instant of time. Clients must at least announce their version. The current scheme is no different from adding a "hey, i support new stuff" announce message, except that scheme only has two versions, whereas the current scheme has an integer range, which happens to be also useful for printing out in chat, and also allows more than one protocol change (unless you want a "hey, i support even newer stuff" message).
The only thing you could argue, is that the announce+request message could have been split into separate announce and request messages, so it is possible to just announce your version when it changes, without having remote clients sending back their versions, if you already have them. However, as i have said before, i consider the traffic infinitesmal, and when the protocol was designed the two were simply merged for sake of simplicity. For upgrades, the local version table is not kept across upgrades, so LCH would always want to do a request immediately following an announce anyway. For joining groups, you will always want to do an announce and request anyway, because there may be new people in the group (their version may have changed since last time you grouped with them). So, basically the only place where the request can be saved is when doing a library upgrade, assuming that the local version table is kept across upgrades.
Now, i've spent hours explaining this (time i should and rather would have spent programming the library). If you don't understand that it cannot be changed in LHC-3.0 i cannot and will not help you further. I promise you that i will take a long hard look at it for LHC-4.0, for example making guild version exchange request only, and perhaps splitting the announce+request into two (to allow the implementation to only do an announce if that is enough), but i will not sacrifice the ability to allow smooth protocol changes in the future by removing the pre-comm version exchange entirely.
Now, i've spent hours explaining this (time i should and rather would have spent programming the library). If you don't understand that it cannot be changed in LHC-3.0 i cannot and will not help you further. I promise you that i will take a long hard look at it for LHC-4.0, for example making guild version exchange request only, and perhaps splitting the announce+request into two (to allow the implementation to only do an announce if that is enough), but i will not sacrifice the ability to allow smooth protocol changes in the future by removing the pre-comm version exchange entirely.
Well I've got a better handle on why you made the choices you did. I don't expect you to change this for 3.0. Having read through the code I understand that it would break the ability of old versions to get version info. It's not a terribly important thing but breaking it is probably not worth the comm traffic you're generating.
Rereading the thread after having a better understanding now I can see how you were trying to explain it but at the same point in time I think you did a lot of hand waving and saying "It's the way it is because it is." Rather than just explaining. I'm sure you thought you were being clear but you weren't.
For 4.0 I'd think that the protocol design should be as follows:
Announce (no request just announce) on joining a group. No announce or request on login to the guild.
All versions from the beginning support an ability to respond to a version request.
All functions for addon use for finding out library versions are designed around the idea that the version information may not be immediately available. Specifically how you go about doing that doesn't really matter, but probably just a request with a callback.
If a protocol change is needed in the future and you want to maintain compatibility with the current major you can add a request on joining a group.
Prior to any protocol change while the announce would be sent it can be entirely ignored by the library.
This would eliminate most of the comm traffic that isn't being used without breaking the design for future needs.
I've made a branch (mainline/branches/guid) with GUID detection in it. If anyone are interessted, it could be cool if you can try it out using your prefered way of casting spells and see if the detected GUID is right. I've tested it with all the ways i can think of. It won't work if auto self cast is off and using /target unless the argument is a valid unitid or the name of a group member. /assist doesn't work unless the argument is a valid unitid (names won't work as it cannot determine the target of an arbitrary name). I don't think it's possible to make these work fully, but i don't think its a very widespread way of casting spells anyway, and currently VisualHeal doesn't even support these (it can't find a valid unit id for the outsider, so it cannot interact with the unit), so it should not be a problem in practise, i guess.
but i don't think its a very widespread way of casting spells anyway
Do not make assumptions. Many of my friends that play arena competitively have very specific macros and/or key setups and usually autocast is off to avoid spells being casted on self accidentally.
In particular, /target is used very commonly in arena macros to target various things such as healing a pet (their names don't change), or destroying an enemy totem.
If you can post some of the most obscure macros, i can add that to my "testing portfolio". Using /target the way you describe should not be a problem (although i'm not sure pet names are valid unit id, but playerpet and party1pet definitly are ok). Destroying a totem is probably not considered healing, so...
Posting to prevent any "where did my posts go" confusion: I've removed the tail end of the arguments over the versioning comm protocol, as those posts contained nothing relevant to the library itself and were primarily complaints and accusations exchanged between individual posters. If you two/three want to keep arguing, please do it in PMs.
Good point about guardians (uncontrollable pets). Some of these are healable (like Shaman's greater elementals for example). Usually these are not critical targets though.
Good point about guardians (uncontrollable pets). Some of these are healable (like Shaman's greater elementals for example). Usually these are not critical targets though.
You can't have unit frames for uncontrollable pets such as guardians though, so the only times they come up in a unitframe is if they were some unit's target.
I just noticed some noise on the shaman forums that the Glyph of Lesser Healing Wave will boost LHW healing by 20% regardless of whose Earth Shield is on the target. I'm going to test this later today and update LHC-3 on the trunk if it turns out to be true.
Shadowed and I have agreed to work together on this, to put our resources to best use, and cause the least amount of trouble for both developers and end users. This means the following:
1) LibPendingHeals-1.0 will be named LibHealComm-4.0.
2) Shadowed will be the lead designer, developer and maintainer of LHC-4.0, and will have full control of the project.
3) I will keep maintaining LHC-3.0, but no further development will be made to it, except for normal maintenance (patch breakage, spell updates, etc.), in the period until it is fully replaced by LHC-4.0.
We believe this is in the best interest of all parties, and hope that you all agree and support this decision.
3) I will keep maintaining LHC-3.0, but no further development will be made to it, except for normal maintenance (patch breakage, spell updates, etc.), in the period until it is fully replaced by LHC-4.0.
I'd like to at least get Beacon of Light support into LHC-3 before the feature-freeze. I will pass on trying to support Glyph of Healing Wave since it would require changes to the API to support these kinds of partial heals.
Yes, Beacon of Light is definitely doable with the current API, so please go ahead with it if you're already started. I will be closing down the guid branch, so don't mind what's in it.
Reposting here, because Shefki said it could be a bug in LibHealComm-3.0:
Seems like the split of PitBull4 to seperate folders caused the upgrade mechanism of LibHealComm-3.0 to break (maybe a LoadOnDemand issue?).
If only PitBull4 contains the latest version of LibHealComm-3.0, only PitBull4 works with it, other Addons don't (tested with VisualHeal and sRaidFrames).
If you manually copy the LibHealComm-3.0 folder from PitBull4 to another Addon using it (overwriting the old version there), everything works again.
I'll need to know specifically which revisions were involved, and it would also help to know if they were loaded on demand on just sequentially during start-up.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumThe analogy is horrible. We're not looking for a needle in a haystack. We found a needle. Might as well remove it from the haystack. Your argument is essentially: Ohh look I found a needle in a haystack but it's such a small thing and unlikely that anyone would ever step on the needle so I'll just throw it back in.
The proper way to handle this from the start was to always include the ability to respond to a version request in the lib. Then have the requests that are only being used to print stuff on demand request and callback to do it.
If you ever needed for protocol reasons to always know the version THEN add announce/request sending on party join.
There is absolutely no protocol consistency purpose to having an announce/request on login to your entire guild. Because outside of the version information it never bothers to talk to the guild it always talks to the group.
I can see the value in having a way to do the request for the guild for version checking purposes without bothering having to get your guild members in a group.
But that functionality has absolutely nothing to do with protocol consistency.
So in reality I think the code would be simpler if the callback request method was used and the only if absolutely necessary due to protocol changes would you need the request/announce message. If you need it you could indeed move back to something similar to what you have. But if you didn't then you'd avoid overhead for something that you may never use.
The GUID stuff wouldn't even be being talked about if Shadowed hadn't brought this issue up. So when Shadowed pointed out the version information was a waste of resources he was doing so based upon the current stable state of LHC-3.0 not having needed a protocol change ever.
If the GUID stuff actually gets bolted on then I suppose you could leave stuff in place. But I don't see the point in bolting it on without a major bump since you'll end up sending double messages for the time being.
You could use the versioning to decide if you could avoid sending the old messages but if only a single old lib is present you'd have to send the old messages. I'd think a major bump including the removal of the old messages would encourage a faster upgrade across the board and would keep traffic to a minimum.
At the same point you could adopt the strategy for avoiding the request/announce traffic until you need it. If it was needed then so be it. But might as well avoid it as long as we could.
You know exactly what I was talking about.
I'll take that as agreement. Thanks. Let's leave the stuff in place given that a protocol change is happening.
Look ultimately our disagreement is simple. You want folks to spend attention to micro-manage really minor stuff ignoring other aspect. I want you to consider other aspects and get the focus of the silly micromanagement. I don't think we'll have an actual agreement ever over this.
Really there is hardly any ground for action here on the protocol side. Take the guild sync out (if it has no extra purpose), and move on to more interesting things.
If the protocol version exchange was designed to be request only, it would never be possible to adjust communication in response to the actual listerners, because the actual listerners can change any given instant of time. Clients must at least announce their version. The current scheme is no different from adding a "hey, i support new stuff" announce message, except that scheme only has two versions, whereas the current scheme has an integer range, which happens to be also useful for printing out in chat, and also allows more than one protocol change (unless you want a "hey, i support even newer stuff" message).
The only thing you could argue, is that the announce+request message could have been split into separate announce and request messages, so it is possible to just announce your version when it changes, without having remote clients sending back their versions, if you already have them. However, as i have said before, i consider the traffic infinitesmal, and when the protocol was designed the two were simply merged for sake of simplicity. For upgrades, the local version table is not kept across upgrades, so LCH would always want to do a request immediately following an announce anyway. For joining groups, you will always want to do an announce and request anyway, because there may be new people in the group (their version may have changed since last time you grouped with them). So, basically the only place where the request can be saved is when doing a library upgrade, assuming that the local version table is kept across upgrades.
Now, i've spent hours explaining this (time i should and rather would have spent programming the library). If you don't understand that it cannot be changed in LHC-3.0 i cannot and will not help you further. I promise you that i will take a long hard look at it for LHC-4.0, for example making guild version exchange request only, and perhaps splitting the announce+request into two (to allow the implementation to only do an announce if that is enough), but i will not sacrifice the ability to allow smooth protocol changes in the future by removing the pre-comm version exchange entirely.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumWell I've got a better handle on why you made the choices you did. I don't expect you to change this for 3.0. Having read through the code I understand that it would break the ability of old versions to get version info. It's not a terribly important thing but breaking it is probably not worth the comm traffic you're generating.
Rereading the thread after having a better understanding now I can see how you were trying to explain it but at the same point in time I think you did a lot of hand waving and saying "It's the way it is because it is." Rather than just explaining. I'm sure you thought you were being clear but you weren't.
For 4.0 I'd think that the protocol design should be as follows:
Announce (no request just announce) on joining a group. No announce or request on login to the guild.
All versions from the beginning support an ability to respond to a version request.
All functions for addon use for finding out library versions are designed around the idea that the version information may not be immediately available. Specifically how you go about doing that doesn't really matter, but probably just a request with a callback.
If a protocol change is needed in the future and you want to maintain compatibility with the current major you can add a request on joining a group.
Prior to any protocol change while the announce would be sent it can be entirely ignored by the library.
This would eliminate most of the comm traffic that isn't being used without breaking the design for future needs.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumDo not make assumptions. Many of my friends that play arena competitively have very specific macros and/or key setups and usually autocast is off to avoid spells being casted on self accidentally.
In particular, /target is used very commonly in arena macros to target various things such as healing a pet (their names don't change), or destroying an enemy totem.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumGood one. I've added a hook for that, and it works in all cases. If you got some more, please post it.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumYou can't have unit frames for uncontrollable pets such as guardians though, so the only times they come up in a unitframe is if they were some unit's target.
1) LibPendingHeals-1.0 will be named LibHealComm-4.0.
2) Shadowed will be the lead designer, developer and maintainer of LHC-4.0, and will have full control of the project.
3) I will keep maintaining LHC-3.0, but no further development will be made to it, except for normal maintenance (patch breakage, spell updates, etc.), in the period until it is fully replaced by LHC-4.0.
We believe this is in the best interest of all parties, and hope that you all agree and support this decision.
I'd like to at least get Beacon of Light support into LHC-3 before the feature-freeze. I will pass on trying to support Glyph of Healing Wave since it would require changes to the API to support these kinds of partial heals.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumSeems like the split of PitBull4 to seperate folders caused the upgrade mechanism of LibHealComm-3.0 to break (maybe a LoadOnDemand issue?).
If only PitBull4 contains the latest version of LibHealComm-3.0, only PitBull4 works with it, other Addons don't (tested with VisualHeal and sRaidFrames).
If you manually copy the LibHealComm-3.0 folder from PitBull4 to another Addon using it (overwriting the old version there), everything works again.
There is a known upgrade problem for one of the earlier revisions, see http://forums.wowace.com/showpost.php?p=283913&postcount=311.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumPitBull4 v4.0.0-beta3-68-gde7fdfb using LHC r93.
VisualHeal 8.12 using LHC r59.
All Addons loading during startup (no AddonLoader or similar style Addon installed).
Everything was ok until PitBull4 was splitted into seperate modules. The PitBull4_VisualHeal module is LoadOnDemand.