Re-think the use of time-related information in XML messages

[markuspeters]

Many of the XML messages contain msec-based information on time instead of, or in addition to, timeslot information.

One rationale for this is that the server implementation may not yet know of timeslots far into the future. The question is then whether the conversion of msecs to timeslots and vice versa is a due or undue burden on the client.

I would argue that when the granularity of timeslots to the broker is sufficient from a strict business logic perspective (i.e. when there is generally no need for the broker to pinpoint moments within a timeslot), then the server should go the extra mile and spare the broker from having to know about msec / timeslot conversion.

[jecollins]

I think this is closely related to the issue of numeric accuracy in xml messages (see issue #360). The question is, whether these messages are intended to be pulled apart by user-written code, or by XStream, which is what generates these formats in the first place. If the messages are being processed by XStream, then why should we care what they look like?

[markuspeters]

But should the server rely on XStream on the client side? The beauty of the XML interface is that you could have a COBOL broker if you wanted. If Power TAC relies on specific client technology, it might as well be built on plain RMI which is probably faster and easier to integrate for client-side Java programmers.

But there is another aspect to this too, which is related to separating universally usable value holders from server-side details. Even if you do use XStream on the client side, you still have "instant" fields in the objects that XStream populates for you. The design question is then: Should "instants" be part of the conversation between client and server if the client never uses them? Right now I don't see a scenario where the clients needs to address or know about instants within a timeslot. If that is indeed true, then there is no good reason for burdening clients with thinking about simulation rates, simulation modulus, etc. The issue then becomes one of the parsimony of the interface's design.

[jecollins]

Although I agree that millisecond precision is not needed, I am very reluctant to permanently "bake in" a one-hour granularity for the whole system. Originally, we were going to use 15-minute timeslots, because there are important markets around the world that operate on 15-minute slots. Some even operate 5-minute slots for balancing. So I might be convinced to switch to a one-minute granularity. It should not be terribly difficult to write a "converter" for Instants that does that. But I do not think that dropping the internal use of joda-time in the server would be a good idea, simply because it is deeply embedded in many places and there are more productive ways to use our time.

[markuspeters]

I agree -- on the server side the use of instants if perfectly reasonable. My remark was directed towards the client side. Right now all the client really needs are timeslots. None of the interactions it has with the server requires it to consider sub-timeslot intervals. In my eyes, removing the timeslots from messages where they are not needed improves the readability of the XML interface.

I concur on that this should be a low-priority CR.

[jecollins]

I think it would be pretty easy to write our own converter for the joda Instant type. One option would be to write out a date-time string, and parse it back in. Another would be to convert it to a timeslot index, but keep in mind that not all Instants have corresponding actual timeslots (future timeslots are only created when the market needs them, past timeslots may never exist). I invite anyone who cares about this issue to try this.

[jecollins]

I believe this issue has been resolved by changes over the last few months.