Doesnt look like its a blocker to me. It isnt a public API. Renaming
should be fine. Jute doesnt serializes the name of the record. So as
long as the fields and opcode are the same, it should be backwards
compatible as well. If you have a simple enough patch for rename I can
include it in 3.4 as well (just to avoid any complications regarding
backwards/forward compatibility later). Sounds reasonable?
On Thu, Oct 27, 2011 at 8:50 AM, Patrick Hunt <[EMAIL PROTECTED]> wrote:
> Submit a patch and slate it for 3.4.0/3.5.0, Mahadev can decide
> whether he wants to include it in the next rc or not.
> On Thu, Oct 27, 2011 at 2:57 AM, Thomas Koch <[EMAIL PROTECTED]> wrote:
>> I've opened ZK-1257 with this description:
>> Understanding the code behind multi operations doesn't get any easier when the
>> code violates naming consistency.
>> All other Request classes are called xxxRequest, only for multi its
>> xxxTransactionRecord! Also "Transaction" is wrong, because there is the
>> concepts of transactions that are transmitted between quorum peers or
>> committed to disc. MultiTransactionRecord however is a Request from a client.
>> I think the rename could also happen after 3.4 since MultiTransactionRecord is
>> not part of the API? If not, I strongly recommend to do the rename before the
>> Thomas Koch, http://www.koch.ro