Hi everyone,
Following discussions with a few of the excellent third-party toolmakers, I have a proposed change to the Notifications XML feed, and wanted to run it by the forum before deciding on which way to go.
There's a weirdness in the Notifications XML, in that if I send harvesters out to gather things, and they succeed in their job, the front-end UI says they did a good job, but the XML gives incorrect information.
THE WEIRDNESS
As an example, here's me sending some cotters out to harvest something.
Front-end UI (in reverse order):
... which is very much a successful mission for a cotter.
However, the Notifications XML for the actual harvesting report reads:
... which certainly says - in the <notificationdetail> field that they were successful in their gathering endeavours. But in the <notificationtype> text, reads "Harvesting - Caravans Disappointed", when clearly they should not be.
THE PROPOSAL I don't know who, if anyone, has code that relies on a <notificationtypeid> of 45 meaning "caravans disappointed", or if anyone compiles or has compiled a lookup table based on the match between the <notificationtypeid> and the text accompanying it...
What I can do is either:
a) continue to provide a <notificationtypeid> of 45 but with different text, depending on the outcome. This could then use the text to say (eg) "Harvesting - Caravans Disappointed Entirely" (if they got nothing) or (eg) "Harvesting - Miners Gather Minerals" (if the miners got some),
or...
b) create new notificationtype ids for different outcomes.
The advantage of a) is that it'll be quicker to implement, and may not involve much code/parser changes for those reading the notifications XML - but give some additional information at a higher level than parsing the notification detail. The disadvantage of a) is that notificationtypeid = 45 becomes a catch-all for "something happened with harvesting".
The advantage of b) is that it continues to provide a clear one-to-one relationship between a notificationtypeid and the accompanying text. The disadvantage is that it adds a bunch more new notificationtypeids that may require existing tools that read from the Notifications XML to alter their codebase, and will take a bit longer for us to implement at our end.
CONCLUSION Those of you great folk who write code that reads the APIs have probably long known that this header wasn't right! However, in fixing it, I don't want to make you do extra work. So, if you're a Tensmoor-type (or Tensmoor himself!) and have a preference for the way I should 'make this right', please do let me know in this thread.
Otherwise, I'll probably do a) and vary the text flexibly, essentially changing notificationtypeid = 45 to a "Something happened with harvesting" broad brush, and providing the 'what happened' in the accompanying notificationdetail text.
Thanks for your time.
SC
|