On Fri, May 24, 2013 at 11:09 AM, Guido Trotter <[email protected]>wrote:
> > > > On Fri, May 24, 2013 at 11:04 AM, Thomas Thrainer <[email protected]>wrote: > >> >> >> >> On Fri, May 24, 2013 at 10:23 AM, Guido Trotter <[email protected]>wrote: >> >>> >>> >>> >>> On Fri, May 24, 2013 at 10:18 AM, Thomas Thrainer >>> <[email protected]>wrote: >>> >>>> The Text backend now parses network UUID (comma separated) and >>>> serializes them in the same form. >>>> The test data is adapted to the new format. >>>> >>>> >>> Would it make sense to have it at the end and optional, as Klaus did for >>> other additions to the text backend he had, so old text backend data is not >>> broken? >>> >>> Are there a lot of text data files around (except tests)? >> > > We have a small secret stash of those, yes. :) > Where are those? Who uses them? Can they be updated centrally? > > >> I'd prefer to break backwards compatibility for internal and test stuff, >> as it's easy to update the (test-)data, and it simplifies the code. Also, >> especially for the text backend, what would happen when we add another >> field? How to decide which one was actually specified if just one was? This >> would just postpone the problem until then... >> >> > Oh, well, the idea there would be that you can't have the only the last > without the semi-last. > eg: > > name|info1|info2 is ok > > as is > > name|info1|info2|info3 > > or > > name|info1|info2|info3|info4 > > or > > name|info1|info2||info4 > > but not just > > name|info1|info2|info4 > > Well, suppose now we add one optional field (4 required, 1 optional, valid field counts: 4, 5), and update 10% of our text files. Everything continues to work and we're happy. Now we add another optional field (4 required, 2 optional, valid field counts: 4, 6). Now those 10% of our text files fail all of the sudden. The poor guy who introduced the second optional field has to understand and fix those issues related to the first optional field. As the format for the text backend is purely internal, not documented, not versioned, not human-readable and not based on any standard, he's gonna take more time to do this compared to the first developer, who actually introduced a new field. And he is going to spend a lot of time counting field counts. I think backwards compatibility is hard, and if there are no really good reasons to do so, I'd drop it. Thanks, Thomas > > Thanks, > > Guido > > -- Thomas Thrainer | Software Engineer | [email protected] | Google Germany GmbH Dienerstr. 12 80331 München Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg Geschäftsführer: Graham Law, Katherine Stephens
