On Wed, Mar 14, 2012 at 3:51 PM, Emmanuel Lécharny <elecha...@gmail.com> wrote: > Le 3/14/12 11:32 PM, Selcuk AYA a écrit : > >> On Wed, Mar 14, 2012 at 3:23 PM, Emmanuel Lécharny<elecha...@gmail.com> >> wrote: >>> >>> Le 3/14/12 10:52 PM, Selcuk AYA a écrit : >>> >>>> HI All, >>>> Sorry for the earlier email. I think I owe some explaination on my >>>> part. The reason for my request is purely technical, does not aim at >>>> oss spirit or any other spirit for that matter: >>>> * There are quite a number of files the txn branch is touching. >>>> * There is no file ownership or review process. >>>> >>>> combined with the timing limitation, it becomes hard for me to track >>>> all changes and cleanup if necessary. When I am doing my changes and >>>> need to change some existing stuff, I usually try to find the guy who >>>> wrote the code and get an ack from him and this usually helps a lot >>>> because even things that look stupid might have some reason to be >>>> there. Please do the same while changing the txn branch.If this >>>> process is followed, we wont have to discuss spirit hurting through >>>> reverting code. >>> >>> np. We can consider that the branch is your sandbox, and i'll keep it >>> alone, >>> just let me know. >>> >>> Look, I'm not trying to collide with what you are doing, Selcuk. Just >>> trying >>> to add the necessary doco and clarification (ie, logs, formating) to get >>> people used with the code. If the code is not finished yet, and can keep >>> away from it atm, just say so. >>> >>> I'm pretty sure we need to communicate more here to avoid such issues : >>> - telling what's going on through the exposure of a roadmap >>> - being more reactive (like just ack mails even if one does not have time >>> to >>> give a clear answer) >>> >>> Regarding the changed code, let me give you some clue about the reason I >>> did >>> those changes : >>> when you log some LogEdit, the records are stored in a file and will have >>> to >>> be read at some point. The externalizable classes have readExternal() >>> methods which expect the byte[] to contain the expected content. >>> Currently, >>> we can do that if : >>> - we have stored only one type of object (like Entry) >>> - we have stored mixed data in a specific order, which allows the code to >>> deserialize the classes without adding a type. >>> >>> I guess that the intention was to deserialize data expecting the >>> serialized >>> structure will always be : >>> - TXN_BEGIN >>> - a DATA_CONTAINER >>> - TXN_COMMIT or TXN_ABORT >>> >>> Here, I see one issues : in one case, we won't have any DATA_CONTAINER >>> (specifically when doing a BIND). We won't then be able to distinguish >>> between a TXN_BEGIN/DATA/TXN_COMMIT and a TXN_BEGIN/TXN_COMMIT if we >>> don't >>> have an extra information, the type. >>> >>> Unless there is something that can be used to make this distinction... >>> >>> Can you enlight me here, in cas I'm doing something wrong ? >>> >> I will have a look at the code your tomorrow morning time and let you >> know. > > > ok, fine. I'll try to be connected early (like 08:00 CET / 0:00PDT) so that > we can discuss on IRC. Let me know if that's fine for you. > > I'll crash in 15 minutes. >
usually email communication and waiting around a day for an email reply should be fine but OK lets discuss this case on IRC. thanks Selcuk > > > -- > Regards, > Cordialement, > Emmanuel Lécharny > www.iktek.com >
