[btech-discussion] Re: Note about modifying hudinfo

[Ernst B. <e.b...@xe...>]

Hi all,

> From: Anthony Parker <as...@ma...>
>
> Just so everyone's clear on some things, we should /really/ avoid modifying
> hudinfo so that it breaks current clients. It's easy enough to update
> current code, sure, but as it gets more popular, there are people out there
> using older versions of HUDs that will probably have to stop working
> because of a change in the core format of commands like 'hudinfo t'.
>
> - Tony

The proposed change was adding two additional fields at the end of the first 
line returned by hudinfo t.
There was never any request to change the "core format" of the result or to 
change the meaning of the other parameters transmitted.
So I don't see any chance that this change could break any client
(in fact, I would consider any client as broken if it doesn't cope with such 
changes)

Most people implementing a hudinfo parser would split the received values 
first (using e.g. StringTokenizer) and then evaluate those values they need. 
Those implementations wouldn't be affected by the proposed changes.

In order to make future enhancements to hudinfo painless, this should be 
explicitly stated in the hudinfo docs:
New commands or additional information appended for existing commands: minor 
version increase

Change in existing parameters or removal of commands: major version increase

In other words: Hudinfo implementations simply should ignore values they don't 
know about...

Bye
	Ernst