söndag 08 februari 2009 20:10:24 skrev Shawn O. Pearce: > Nigel Magnay <nigel.magnay@xxxxxxxxx> wrote: > > > A problem (big problem) with serialization is that it often leads to > > > fragile interfaces. One might want to have precise control over > > > the serialization so a change in the implementation doesn't affect > > > compatibility. Serializing AnyObjectId should not depend on the > > > implementation de jour. Second, how do we handle subclasses? > > > > > > But maybe leaving it this way would be our way of saying that > > > the interface may break at any time, promise. > > > > Well, we can of course implement writeObject / readObject (or do so > > if/when compatibility breaks, and it's cared about) > > > > That's how I tend to view it anyway (may break at any time) - you > > can't just update a jar library to a significantly new version and > > expect it all to stay compatible. Also for half my use, it's not for > > persistence, it's for transferring over the wire to a slave process. Over-the wire has the same issue. Clients and servers often run with slightly different versions. > > Thinking a bit more clearly, I probably don't need AnyObjectId, just > > ObjectId - but I've also missed RefSpec and URIish as they're used in > > RemoteConfig.. > > Here's my two cents... we can do this, but only if we implement > Externalizable and do the read and write ourselves so we have a > stable format. > In the case of any of the types you are discussing there is an easy > canonical form for them to be written on the wire, or to read back: > > ObjectId - the 20 byte SHA-1 > RefSpec - the string form as it appears in the config file > URIish - the string form as it appears in the config file with our without the password? > RemoteConfig - a map of keys/values as it appears in the config I lean toward the do it correctly side too. Don't forget a few test cases with pre-recorded serializations to verify compatibility over different versions of jgit. -- robin -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
