Minutes of the call 1 September 2014

DAISY Online Delivery Protocol (DODP) Refresh call

Monday 1 September 2014 11am UTC

Notes of the meeting

Introductions

Dave Gunn, Johan Abbors, Fredrik Schill, Edmar Schut, Dominic Labbé, Takuro Shiroki, Hiro Fujimori, Andrew Furlong, Per Sennels, Geoff Gilmour-Taylor, Roger Beatty, Jelle Martijn Kok.

Regrets: Claudio Montalban.

Actions:

Rolled - Reading system developers: Suggestion that you might like to submit feedback on areas of documentation which would benefit from clarifications to address differences in service implementations (feedback already submitted by Humanware).

Rolled - Dave: migrate the documents from the Google site to GitHub.

Rolling - All: please engage with the requirement issues on GitHub to suggest details to enhance the requirement.

Backwards compatibility

We have talked around backwards compatibility on some of the earlier calls prior to the formal collation of requirements, so this is the ideal time to discuss and agree a requirement on backwards compatibility. In discussion CNIB have proposed the following two requirements:

Requirement N: Backwards compatibility of devices

What: A DODP 1.1 device must be able to communicate with both DODP 1.0 and DODP 1.1 service endpoints.

Use case: (a) A user purchases a DODP device without having to know what version the service is that they want to connect to. (b) A developer creates a DODP client that will work with either a 1.0 or a 1.1 service without needing to specify two device behaviours based on server version.

Notes : Refers specifically to using the same SOAP client on both services.

Source:CNIB

Why Device-side half of backwards compatibility.

Requirement N+1: Backwards compatibility of services

What: A DODP 1.1 service endpoint must be able to communicate with both DODP 1.0 and DODP 1.1 devices.

Use case: A service provider wishes to serve devices that may support 1.1 or may only support 1.0, without needing to code two different behaviours based on device version.

Notes: "Service endpoint" is a synonym for "port" in WSDL terminology. It follows from this requirement that the WSDL and XSD schemas specified in 1.0 are not changed in 1.1.

Source:CNIB

Why: Service-side half of backwards compatibility.

Dave introduced the topic, outlining the proposed requirements from CNIB and opened the floor for discussion.

Roger - one of the elements the second proposal is that the most important thing we believe is we need a declaration as to whether or not the schemata is going to be altered or not. If the schemata is to be modified to maintain backwards compatibility each end of the conversation must be able to handle both versions of the data formats. If the schemata is to remain unchanged then it will be fairly simple or less complicated, and this 1.1 update becomes more about updating the documentation, primers, reference implementations etc. If we’re going to change the schema, then the level of complexity at both the player and server end goes up, and we to ensure everyone is aware of that and is willing to buy in to that.

Johan – we have a lot of requirements now on GitHub that we are supposed to address, and most of them can’t be addressed without making changes to the schemata. So I’m concerned that this upcoming version would contain only a few minor tweaks - which nobody would implement because the protocol would still contain many shortcomings.

Roger – I’m ok with that, I just need to ensure that everyone understands that once the schemata changes that the level of complexity goes up, and the support costs go up, and the return on investment goes down.

Fredrik – I think from MTMs point of view, we are ok that the complexity goes up. What we see today is problems with the efficiency in communications, and we can see that by adding more complexity in the protocol we will achieve more efficiency in communication, and with that we can save bandwidth and server capacity, and provide quicker communication for the users and a better experience. So from our point of view we are ok with the increased complexity if the benefit is better features in the protocol.

Jelle – I think only one party should be able to do both versions of the protocol, and I think it will probably not be possible for the libraries to do, as implementing both may result in partial functionality. So if the libraries are required to support both versions, one of those versions is likely to be a very lightweight edition of the system. So I think that the players might be required to implement both versions, and that might be what we end up with.

Roger – I believe the server has to honour the communications with both types of devices if we alter the schemata. In the case of CNIB and other libraries around the world, there are users in play and we are in production, by the time the protocol is signed off and agreed to we will have a larger mass of 1.0 players in the field, and the conversion becomes very delicate unless we have multiple services operating. That’s why I’m saying the level of complexity goes up very quickly if you have an existing implementation.

Fredrik – I agree. I think it also has to be on the server, I think it’s necessary and I hope we can find a way to make it possible, perhaps in the first call that is made to the server to identify what client is connecting. Hopefully we can make that part compatible, but I think also the server has to be able to support both kind of clients because there are many devices out there. We have perhaps 5-6,000 active devices in Sweden already.

Dominic – it’s clear that we need to think about the migration path. The last thing that we want is where we just create more diversity in terms of combination in the field. The objective was to fix some problems, including not to have more special cases, so we need to make sure the transition is not that complex. We definitely need to make sure we address some of the problems, otherwise libraries in some cases won’t even move across, so we need to consider the benefit. As Roger mentioned we need to ensure a return on investment for all the stakeholders that need to do the transition.

Johan – I doubt that a service will be able to provide both 1.0 and 1.1 simultaneously, or at least communicating over the same ports.

Fredrik – I think it can be possible if the new version also contains the old code.

Johan – but still the first call has to be logon request, and we can’t add anything to that process to indicate the client reading system version.

Fredrik – we could add an option parameters to it, and a 1.0 would not include them and the server would know it’s an old client. A new client which supports 1.1 that includes the new parameters and connects to an old server would get the fall-back and in that case would detect a 1.0 server and continue without the new parameters.

Johan – it might be very complex, and require a lot of extra investment from the libraries.

Roger – and also extra investment from the player vendors because not only do they need to be smart enough to handle multiple server types, but they need to react and still be tested and approved at every level. I think there’s a lot of testing in this.

Roger – I’m not saying that we should not change the schemata, but everyone on the call has to be fundamentally aware that if we move forward with this, there’s a price tag.

Andrew – not surprise from our involvement that we accept there needs to be change, as actually think that this is not be a wasted investment, but instead builds on the investment we’ve made. There are some good points that have been raised about supporting players in the field, and we’re really going to need the support and involvement of the player manufacturers as we move forward, because without them whatever we do is not going to work. Someone mentioned that this would need to be a player side implementation, and I’d tend to agree with that. While I also think that the provider can choose if they migrate to 1.1 or remain with 1.0, the problem may arise that player will no longer support 1.0. If we don’t do something I think the risks are much higher than by doing something. So Vision Australia would be supporting and understanding that there are risks and costs, but the long term benefits outweigh the short term risk.

Jelle – I agree with it. There are already libraries which are active in the field and I don’t think we can require them to upgrade – which will probably be too costly. It might be wisest to let them choose, and if they want to support both protocols they might need to have two ports to the system. It should be up to the library wants to adopt versions or one. Even for the players it might be optional because some devices cannot be upgraded, and those will probably be stuck with version 1.0. I guess it’s best for a player to support both versions, but that is really down to the developer of the player. The conclusion is it will add extra cost.

Andrew – something else which has come to mind is the importance of the updates. For example what are things which will add functions and save costs.

A few people in presentations have already discussed upgrading players which have already been dispatched into the field, and that’s something that we experience and would like to see implemented in the protocol – to streamline the configuration, upgrading, firmware updating and so on of an online player – is going to save a lot of time and costs for the organisations compared with having to do it manually, having players returned, modified and so on.

So there are some things which are going to save time and money in the long run, and other things which may not.

Edmar – I’m a little in doubt if there is any benefit to implementing a version 1.1 since it’s a lot of effort and investment, maybe we should skip 1.1 and go to version 2.0 straight away.

Roger – for the 1.1 I’m not saying that we don’t do it, but that if we understand that the schemata doesn’t change 1.1 can be the increased documentation around the protocol, reference implementations, examples, primers, all the things that were not done on 1.0 that would enhance the ability and understanding of both the server side developer and the client side developers without changing the schemata. And then go to 2.0 which is going to be a full thing. I’m not voting either way, I’m just saying we all need to understand this is going to cost a bunch of money.

Andrew – don’t we end up in the same place though?

Roger – it gives us a greater amount of time. If we have an understanding that 2.0 is going to be X years out, and if we have a gain in play that allows the client software and firmware to be updated and configured online in real time, those positionings could save us the hassle when we go to 2.0.

Someone mentioned that they have 5,000 players out there. If there’s no way to update those 5,000 players or even do it in a timely fashion, the service will have a huge interruption, and that’s what I’m worried about at CNIB. By the time it all goes live I’m expecting to have a significant number of players in the field, so I need to understand that the transition plan from 1.0 to whatever is well thought out and cost effective.

Johan – I see your concern, we have offline discussion amongst the editors and Claudio presented 3 paths we could take, and in one he mentions that device manufacturers may not be able to support both versions due to limitations in computing power, and I share his thoughts on this, and believe it should be up to the server implementations to support both versions.

Dave – Edmar raised a very good point asking should we just jump to version 2.0 and the timescales involved in that were highlighted by Roger, this working group isn’t currently tasked with what we’re calling 2.0 which is incorporating all of the enhancements that were proposed initially, but that is something which we could take back to the DAISY Board and make a recommendation, but there are some significant issues around timescales for implementation that I suspect several people on the call wouldn’t necessarily agree with.

Dominic – I think there’s still room for a 1.1. Following what Roger said, we need to make sure the transition is not that complex, that it is backward compatible if you add new attributes, you give an easy way to upgrade as long as a player and a server is compatible. I think there is still significant benefit to the exercise of 1.1 without changing too much and without requiring too much on both the server and client side. I would not close 1.1 and postpone everything to 2.0. The danger with 2.0 is like when we had the transition from DAISY 2.02 to NISO, it was the best thing in the world, but there are like 2 libraries in the world that really implemented NISO, and in practice most of them are still releasing DAISY 2.02 books. So we need to ensure if we have a 2.0 that it will be used and implemented by libraries. The last thing we want is a white elephant as version 2. Maybe we can at least try to improve 1.1 without making too many changes so the transition is smooth and not that costly.

Dave – I guess at the same time there will be concerns about the benefit of implementing 1.1 if there aren’t seen to be significant gains from doing so, people might wait to see how far off 2.0 is.

Dominic – I agree, unless we are really good at making an improvement which really makes a difference for libraries, if we’re just changing 1.1 to address theoretical problems or doesn’t change anything for specific libraries of course they won’t change, but call it 1.1 or 2.0 most libraries would make a business decision based on cost benefit, and us as a player manufacturer would be following as soon as there’s at least one of them, so usually the player manufacturer ends up with no decision to take – we just have to follow where the market is.

Andrew – I think there’s also several organisations, I know Vision Australia is one, where we have implemented some extensions to the protocol as a necessity, certainly one of our drivers for this update was to bring that to everyone so others could benefit knowing it’s something they’re going to need at some point, based on our experience. There are other organisations that have implemented similar custom implementations who would like to see those built into the standard, to have those adopted across the board to ensure interoperability, and achieve what we’re all looking for which is players which operate across services.

Roger – there is one suggestion that has been discussed at CNIB, which is to have two servers, and actually have a 1.0 server on one URL, and a second server on a different URL which would respond to the 1.1 players. That would be an administrative transfer as the new devices roll out, and some sort of administrative transfer as the new devices roll out, and then some transition exercise to circle all the old player in the field until the old server is unused. It’s a horrible manual way to do business, but it is a way to get existing implementations with a large number of players in the field upgraded over time to 1.1 that has some form of a modified schemata. It is doable, I just keep going back to the cost and the value.

Fredrik – I don’t think it has to be such a bad idea. I know here in Sweden at least are considering having two URLs and slowly migrating all our clients. I could look upon that as a fairly stable transition actually.

Andrew – and we would potentially do the same.

Dominic – honestly I think it’s the only practical way to do so, because everything else would involve the assumption that everything can connect at the same time. But some people won’t connect for a while because of vacation or something. You just can’t change a server to go live and expect all the devices in the field to update within 24 hours, so I think that would be the only practical way since we have no provision in 1.0 to ease that transition. You probably wouldn’t want to do it anyway as you’d want to test with a few users first and build up gradually.

Dave – reflecting on the conversation so far, if we take the second proposed requirement first, it is starting to feel more like a recommendation than a must.

Roger – I think we could actually, if the entire group agrees and understand the costs of changing the schema, CNIB will request that that requirement be withdrawn. Perhaps we could have a quick vote to ensure that everyone understands that we’re now talking about changing the schemata, and the price point goes with that decision. If everyone agrees we will ask for the proposal to be removed.

Fredrik – perhaps we should ask the manufacturers if they are ok implementing both versions in the players.

Dominic – I’ll give the same answer I have before, this is a server driven business, so if an organisation decides to implement a server of 1.1 or 2.0 and we want to business we need to support it. As a player manufacturer I have probably close to zero choice. If there is a new standard, and we hope that there is, we hope at least that the rate of adoption is high enough to justify the cost. Right now I’m spending a fair amount of money making customisations for differences in implementation, custom requirements which are mixed with the standard. If 1.1 address that problem in a standard way and a number of libraries adopt it then we will make the change, but we don’t have much of a choice.

Jelle – I fully agree with Dominic, I couldn’t express it better.

Andrew – from a service providers point of view we want all the players to work with our service, which I think is another reason why it’s important that we harmonise the protocol.

Dominic – I would say the protocol and its implementation, sometimes people have interpreted the protocol in different ways, and that’s where we have delays in implementing different versions.

Fredrik – I think if we make this decision now and make a better protocol it will give us a better chance to have a better following by everyone.

Dominic – agree, but on the other hand if the delta is too big some libraries will want to stay where they are, so too much change could lead to small adoption rates.

Fredrik – I agree, and think that’s why we should focus on 1.1 issues now and not add everything that could be in a later 2.0 version because that could make the jump too steep.

Takuro – player side for us, as Dominic mentioned, when a protocol is expanded and adopted we are happy to support the new protocol also. We would also like to minimise the customisation that each server demands. When all the servers are offering the same behaviour, then we can simplify the user interface and minimise the cost of customisation. At this point we would welcome the new version.

Johan – our discussion have brought me to an idea of ranking the requirements on Github, maybe 1-3 for severity of modification, and how much people want them in the new version.

Andrew – that’s not a bad idea as it would give people ownership of what has been put forward.

Johan – although it will be hard to do before proposed solutions for requirements.

Dave – so is this something which is worth progressing once we’ve explored more of the detail for How the requirements might be implemented?

Dominic – I think it would be a good exercise to assess complexity, but on the other side we need to rate the value of change. In an ideal world we would be making small changes which offer big value. The dangerous thing would be making a big modification to fix something small. So if we’re to do a cost review, let’s do a cost benefit review because sometimes there are things which make a lot of difference for many libraries, and sometimes there’s something very specific to one server or only provider that doesn’t matter to other people. In the ideal world we would implement small changes which matter the most to many libraries and player implementations – maximising the result while minimising the investment would be my definition of 1.1 compared to 2.0.

Fredrik – I think to have a view on this we would need to have suggested implementations for each requirement, otherwise we will be grading things without fully understanding them.

Several people - Agreed

Dave – so I think those are some great ideas to help us make the difficult decisions once we’ve explored the implementation options for the requirements, and I absolutely agree with Dominic’s point around identifying the value. Just to return us to the backwards compatibility topic, it feels like we’re almost at a place we can record. For the second requirement Roger suggested we have a show of hands to indicate people understand the additional costs which come with updating the schemata, and if everyone is comfortable with that we remove the requirement. Is that a fair assessment?

Roger – yes, please remove it.

Geoff – I would also say this modifies the first requirement proposed. It sounds more like we’re expecting service providers to have two ports, one for each version, in which case I don’t think the first version applies either.

Dave – lets tackle these one at a time. We were nearly there with the second requirement. Is there anyone who would object to removing this as a requirement?

No objections recorded.

Decision: proposed requirement N+1 on “Backwards compatibility of services” removed with the understanding that the schemata will be open to change in 1.1, and all parties acknowledge the costs involved in that change.

Dave – as a requirement we’ve agreed that’s out, we want to consider adding a recommendation for people implementing a 1.1 services that consider maintaining support for 1.0, but we’ve already identified associated costs and complexities in that process.

For the first proposed requirement “Backwards compatibility of devices” it feels like we’ve also agreed that this is no longer a must, but we may want to consider keeping this in as a recommendation.

Roger – I think both should be absolutely removed, once you change the schemata the cost value to the manufacturers is not going to be there. You’re going to need a version 1 firmware and a 1.1 firmware, and they don’t necessarily have to be on the same device. Lets not burden the manufacturers with that cost, lets remove both of those requirements.

Fredrik – agreed, and I think it may be better for us to use a new name like 2.0 which would indicate to all that it is no longer compatible with the old version.

Dominic – I agree that if the protocol is not backwards compatible the first digit should be increased.

Dave – we’ve previously identified a naming convention which we will follow once we’ve established the constant of this update. I agree it’s starting to look more like a 2.0, but to keep the current documentation clear lets preserve the convention of calling this 1.1.

Dave – The proposal is to remove the proposed requirement “Backwards compatibility of devices” any objections?

No objections recorded.

Decision: remove proposed requirement “Backwards compatibility of devices”.

Dave – is there anything we would like to put in about backwards compatibility? It feels like we’ve talked right around this, but just to guarantee we don’t revisit this again is there a statement we should insert?

Roger – I don’t see the need for a statement now we’ve agreed that the schemata is going to change. We have discussed this well, so we know that backwards compatibility at the device and at the server have left.

Fredrik – I would agree.

Dave – I think this has been a really good use of this meeting.

There were a few other items on the agenda for us to progress today, it feels like we won’t have time to do them justice today, so we’ll roll them to next week and add a couple more requirements.

Next steps

Dave – on subsequent calls we will discuss a handful of requirements identified by the editors to flesh out some of the detail. We will still be asking people to visit the issue tracker on Github to help identify the possible methods of implementing the requirements. The calls will be used to pick up some of the requirements that either haven’t been discussed on the issue tracker, or are complex topics which are better handled through discussion on the calls. So for the next few weeks we’ll be going through a selection of requirements, talking over some solutions and hopefully progressing them.

Please do visit the Issue Tracker on Github. If you are able to propose solutions and progress the requirements it would be much appreciated.

https://github.com/daisy/DAISY-Online-Refresh

Rolling Action all: please engage with the requirement issues on GitHub to suggest details to enhance the requirement.

AOB

Johan – question about migrating Google pages to Github, need a hand?

Dave – thanks I will let you know if it becomes more difficult than anticipate.

Next meeting

Monday 8 September 11am UTC.