 |
|
 |
|
|
Author |
Message |
Lokorin
Site Admin
Joined: 03 Apr 2006
Posts: 697
|
 Posted: Tue Jun 20, 2006 7:46 pm Post subject: Drastic changes to the server interface? |
|
|
Status: Included in version 1.4.0
I have been looking at the server interface specification and how it should be modified to allow suggestions such as inverted reward reporting. The thing I don't understand is that there are separate functions for a lot of things (such as Add raid and Add raid attendees) when one function should be enough.
What I'm currently considering is to remove Add raid, Add raid attendees, Add loot item, Add raid batch and Add event and replace them with Add day which would be given all the needed information along with a few "suggestions" about how the client want the data displayed. The suggestions could be something like "please compress the data as much as possible before displaying it mr server" or "please display reward ocasions where people were not present instead of the ones when they were present". This would be suggestions from the client as to how it would like the contents displayed, but the server is the one who ultimatly makes the choise and may ignore the client's suggestion. This would be a drastic change, hence I want to hear some thoughts about it. I'm figuring that there must be a reason why it already isn't like that.
As I see it:
Pro* Less coupling between the client and server. The server can run whatever software it wishes as it is ultimatly the part that decides how the day should be represented, the client just provides the data and makes requests in what way the data should be represented (which the server may ignore).
* The client doesn't have to care about what the server can and can't do, that is left to the server.
Con* The client has less control (although this is not necessarily a bad thing).
* What happends if some new data should be displayed on the server a few versions from now? The new function has to be designed so that it maintains backwardscompatibility so that both an old client can communicate with a newer server and vice versa.
Another question is exactly how much infromation that the server should be given, this is what I can come up with at the moment:
* The duration, participation, reward, zone and note of each reward interval.
* The time, participation, reward and note of each event.
Anything else? The duration of the entire day?
Last edited by Lokorin on Wed Aug 23, 2006 3:56 pm; edited 3 times in total |
|
Back to top |
|
 |
Lokorin
Site Admin
Joined: 03 Apr 2006
Posts: 697
|
| Posted: Wed Jun 21, 2006 6:02 pm Post subject: |
|
|
I would suggest the following specification for Add day:
External name
addDay
Parameter count
four
Return type
boolean
Action
Adds the entire day, as described by the first parameters, to the server. I may be represented in any manner that the server sees fit. The server may choose to ignore the client's representation suggestions, as specified by the second parameter.
Parameters
Any array entries beyond the specified ones should be ignored. Additional parameters should be allowed but ignored.
1. array - An array describing the day that should be added, the array contains the following entries.
1. array - An array containing the following entries
(none, reserved for general properties of a day)
2. array - An array containing entries that each describe one loot item dropped during the day. Each entry is an array which contain the following entries.
1. string - The name of the item that dropped.
2. double - The price payed for the item (in DKP).
3. string - The name of the person that bought the item.
3. array - An array containing entries that each describe one reward interval during the day, the entries are sorted chronologically. Each entry is an array which contains the following entries.
1. int - The timestamp (seconds) describing the point in time when the reward interval began.
2. int - The timestamp (seconds) describing the point in time when the reward interval ended.
3. double - The number of DKP that should be rewarded to each participating member.
4. array - An array of strings, each contained string represents the name of one member that should be considered present during the reward interval.
5. string - The zone that the reward interval occurred in, may be emtpy.
4. array - An array containing entries that each describe one event present in the day, the entries are sorted chronologically. Each entry is an array which contains the following entries.
1. int - The timestamp describing the point in time when the event occurred.
2. double - The number of DKP that should be rewarded to each participating member.
3. array - An array of strings, each contained string represents the name of one member that should be considered present during the event.
4. string - A note describing the event, may be emtpy.
5. array - An array that describes the high participation bonus, containing the following entries.
1. double - The number of DKP that should be rewarded to each member with high participation.
2. array - An array of strings, each contained string represents the name of one member that should be considered to have participation.
2. array - An array representing requests for each part of the day. E.g. the first array contains requests for how the general properties should be represented (remember that the server can ignore anything that it feels does not make sense) and the second array contains requests for items. Each request array is an array with the following entries (replace "[foo]" with the part that it corresponds to):
1. boolean - vebose: If true then the server should print each [foo] in an verbose way as possible, if false then the server should try to keep the verbosity down when representing a [foo]. Note: This works on a per-part basis, e.g. this being true is not a request for keeping the number of represented [foo]s down, rather it is a request to keep the verbosity of each [foo] down.
2. boolean - compress: If true then the server should represent as few [foo]s as possible, compressing data when possible. If this is false then the server should represent each [foo] individually, without any compression.
3. boolean - invert: If true then the server should represent the [foo]s as a whole by representing each missed [foo]. If false then the server should represent the [foo]s as a whole by representing each [foo] not missed.
I'm sure I have forgotten a few things, so this would be a good time to find them. But I think that this kind of specification would be fairly good at both fitting different server DKP software and allowing newer clients to be used with older interfaces and vice versa.
Feedback please. |
|
Back to top |
|
|
Lokorin
Site Admin
Joined: 03 Apr 2006
Posts: 697
|
| Posted: Thu Jun 22, 2006 7:52 pm Post subject: |
|
|
Another way would be for the server to provide a list of all available representations and then let the user choose one. |
|
Back to top |
|
|
Lokorin
Site Admin
Joined: 03 Apr 2006
Posts: 697
|
| Posted: Fri Jun 23, 2006 9:46 am Post subject: |
|
|
I have throught a bit about it and the second alternative sounds better, mainly because it allows the plugin to add new ways to display raids without having to alter the client, |
|
Back to top |
|
|
impishfae
Joined: 19 Jun 2006
Posts: 125
Location: Australia
|
| Posted: Sat Jun 24, 2006 1:22 am Post subject: |
|
|
I too like the second idea. The client shouldn't have to have any awareness of what capabilities the server has. So providing the choice back to the user sounds just dandy.
Encapsulation! |
|
Back to top |
|
|
Lokorin
Site Admin
Joined: 03 Apr 2006
Posts: 697
|
| Posted: Sat Jun 24, 2006 10:22 am Post subject: |
|
|
Great, the draft has been updated andI will start working on implementing it. I have updated the to do list with all the latest suggestions and marked the ones that are currently being worked on so that there is no overlap. |
|
Back to top |
|
|
|
|
