| Thread Previous • Date Previous • Date Next • Thread Next |
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
<mailto: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.
-- Aditya.
| Thread Previous • Date Previous • Date Next • Thread Next |
