acmeattic-devel team mailing list archive

[Karthik Swaminathan Nagaraj <nkarthiks@xxxxxxxxx>]

On Mon, Jul 12, 2010 at 2:46 AM, Aditya Manthramurthy
<aditya.mmy@xxxxxxxxx>wrote:

>  On Monday 12 July 2010 10:36 AM, Karthik Swaminathan Nagaraj wrote:
>
> On Sun, Jul 11, 2010 at 9:58 PM, krishnan parthasarathi <
> krishnan.parthasarathi@xxxxxxxxx> wrote:
>
>>
>>  The main disadvantage of 'integrating' pycrypto into our codebase is
>> that we must maintain that piece of code as well. We must keep track of
>> pycrypto's development cycle to do this. Our dependency of pycrypto is like
>> any other s/w dependency. This needs to be resolved in packaging of
>> software. eg tarball, .deb, .rpm, .egg, etc
>>
>
> Well, there may be a little more to it. When we package for say mac or
> windows, it would make sense if there are few dependencies, as I don't think
> either of them have a good way to handle dependencies. Also, if we make
> users install dependencies like pycrypto, we would have to package ours very
> carefully, paying attention to where the dependencies may have been
> installed, etc. Considering that we may have to manage with few developers,
> we should try to keep development on all platforms as uniform as possible.
> It would be too time consuming to consider each OS's quirks separately.
>
>
>
>>
>>> The pickle documentation page does not seem to say when it will crash.
>>> Can you be more specific? Unpickling an older version object will simply
>>> give an object having a different set of attributes than the version that
>>> the newer software is expecting - this need not crash anything right? This
>>> can be handled in code itself keeping backwards compatibility in mind.
>>>
>>  The messages are internal to our software and we can ensure we don't
>> have our server and client software advance at different speeds in their
>> message format compatibility.
>>
> Is that possible easily. We are surely going to have clients who update
> their software later than how fast servers are updated, and our product
> releases. I think its a safe choice to have compatibility now.
>
>
> Does using a cross-language serialization technology like ProtoBuf or
> Thrift actually improve our backwards compatibility? I think not - cross
> language development is not the issue here. All we are talking about is an
> updated message structure that is exchanged between server and client. If
> the message structure changes, whether we use ProtoBuf or Pickle, we will
> have to write special cases code depending on what structure the message
> has, and which version of the software creates messages with that structure.
> When we update our message structure, we just need to make sure that we
> don't remove the previous message structure class. We will have to use new
> message structure classes and write code that handles each message structure
> in a backwards compatible way. To ease the pain of such work, we should
> probably not worry about backwards compatibility (and change the original
> message structure, as we find convenient), until we are ready for beta or
> stable release. Hope I haven't misunderstood something here. Please correct
> me if I am wrong.
>
> The more important thing is to concentrate on performance. If ProtoBuf or
> Thrift is actually more efficient than cPickle, it would make sense to use
> those. However, I think that it is unlikely, as those technologies are
> written with cross-language compatibility
>
>
in mind.
>

It is unclear at this point if protobuf's performance will be improved. And
since Thrift is in its initial stages, I am slightly apprehensive in
adopting it.
Up until now, I was assuming that we have to use Python classes to pass
information. I realized that we could use Dictionaries with variable names
mapping to their (heterogeneous) values. (Pardon the python ignorance).
Wrt. backward compatibility, I am fine if we are safe in writing code.
By safe I mean, cases where a new code is reading a message from old code.
It cannot assume the presence or absence of a variable.
So cPickle it is!


>
> --
> Aditya.
>
> _______________________________________________
> Mailing list: https://launchpad.net/~acmeattic-devel<https://launchpad.net/%7Eacmeattic-devel>
> Post to     : acmeattic-devel@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~acmeattic-devel<https://launchpad.net/%7Eacmeattic-devel>
> More help   : https://help.launchpad.net/ListHelp
>
>


-- 
Karthik