commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matthew Pocock <turingatemyhams...@gmail.com>
Subject Re: [codec] getting the bmpm code out there
Date Thu, 11 Aug 2011 19:55:17 GMT
Hi Sebb,


> The reason I raised the issue was that the API seems to be currently
> in a state of flux.
>

The BMPM code has not appeared in a previous release. It is a discrete
addition that doesn't alter any existing code, and as far as I know,
currently no 3rd party code relies upon it. Right now on trunk, it is a
StringEncoder.


> In this case, because the BMPM code is new, it might be possible to
> relax the requirement somewhat, so long as the code API is documented
> as being unstable.
>

I've no problem with marking it as new or unstable or whatever the right
word is. While it extends StringEncoder, the API is stable. Although there
may be more flux with the finer details of the string you get out for the
string you put in as we fix bugs and update the rule tables, this shouldn't
alter how clients (users of the API) call this code, only the quality of the
results they get back.


>
> If we do have to change BMPM in a way that is not binary compatible,
> then all code that uses the BMPM classes will need to be updated.
>

Understood. I think this only becomes an issue if/when Encoder becomes
generified, and at that point clearly we need a big version bump, with all
the associated changes, and all encoders and their clients would be equally
affected.

Does that help, or have I further muddied the waters?

Matthew

-- 
Dr Matthew Pocock
Visitor, School of Computing Science, Newcastle University
mailto: turingatemyhamster@gmail.com
gchat: turingatemyhamster@gmail.com
msn: matthew_pocock@yahoo.co.uk
irc.freenode.net: drdozer
tel: (0191) 2566550
mob: +447535664143

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message