{"thread":{"id":"17624","subject":"[PATCH JGIT] Minor : Make ObjectId, RemoteConfig Serializable","startedAt":"2009-02-06T21:15:29Z","lastAt":"2009-02-08T19:47:45Z","messageCount":6,"participants":["Nigel Magnay","Robin Rosenberg","Shawn O. Pearce"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"103559","messageId":"320075ff0902061315g3f8b9c9bj92f528e700d59c50@mail.gmail.com","threadId":"17624","inReplyTo":"320075ff0902060702n7573aaecu9054626ee9a6991@mail.gmail.com","subject":"[PATCH JGIT] Minor : Make ObjectId, RemoteConfig Serializable","fromName":"Nigel Magnay","fromEmail":"nigel.magnay@gmail.com","sentAt":"2009-02-06T21:15:29Z","receivedAt":"2009-02-06T21:15:29Z","isPatch":true,"sender":{"key":"nigel.magnay@gmail.com","avatar":"https://gravatar.com/avatar/d85cf38287bef3a8e4fa02358d2756d7589f8676c5eeb881ce2f6d731e4526c3?d=mp&s=160"},"body":"Make AnyObjectId and RemoteConfig Serializable.\nWhen using jgit as a library in other tools, it's helpful to be able\nto use the nice, tested bits of jgit rather than String, but need to\nbe able to serialize them.\n\nSigned-off-by: Nigel Magnay \n---\n .../src/org/spearce/jgit/lib/AnyObjectId.java | 3 ++-\n .../org/spearce/jgit/transport/RemoteConfig.java | 3 ++-\n 2 files changed, 4 insertions(+), 2 deletions(-)\n\ndiff --git a/org.spearce.jgit/src/org/spearce/jgit/lib/AnyObjectId.java\nb/org.spearce.jgit/src/org/spearce/jgit/lib/AnyObjectId.java\nindex e2f70ca..532174b 100644\n--- a/org.spearce.jgit/src/org/spearce/jgit/lib/AnyObjectId.java\n+++ b/org.spearce.jgit/src/org/spearce/jgit/lib/AnyObjectId.java\n@@ -39,6 +39,7 @@\n\n import java.io.IOException;\n import java.io.OutputStream;\n+import java.io.Serializable;\n import java.io.Writer;\n import java.nio.ByteBuffer;\n import java.util.Arrays;\n@@ -52,7 +53,7 @@\n * with this instance can alter at any time, if this instance is modified to\n * represent a different object name.\n */\n-public abstract class AnyObjectId implements Comparable {\n+public abstract class AnyObjectId implements Comparable, Serializable {\n static final int RAW_LEN = Constants.OBJECT_ID_LENGTH;\n\n static final int STR_LEN = RAW_LEN * 2;\ndiff --git a/org.spearce.jgit/src/org/spearce/jgit/transport/RemoteConfig.java\nb/org.spearce.jgit/src/org/spearce/jgit/transport/RemoteConfig.java\nindex 5bbf664..7949612 100644\n--- a/org.spearce.jgit/src/org/spearce/jgit/transport/RemoteConfig.java\n+++ b/org.spearce.jgit/src/org/spearce/jgit/transport/RemoteConfig.java\n@@ -38,6 +38,7 @@\n\n package org.spearce.jgit.transport;\n\n+import java.io.Serializable;\n import java.net.URISyntaxException;\n import java.util.ArrayList;\n import java.util.Collections;\n@@ -53,7 +54,7 @@\n * describing how refs should be transferred between this repository and the\n * remote repository.\n */\n-public class RemoteConfig {\n+public class RemoteConfig implements Serializable {\n private static final String SECTION = \"remote\";\n\n private static final String KEY_URL = \"url\";\n--\n1.6.0.2\n"},{"id":"103680","messageId":"200902080313.21785.robin.rosenberg.lists@dewire.com","threadId":"17624","inReplyTo":"320075ff0902061315g3f8b9c9bj92f528e700d59c50@mail.gmail.com","subject":"Re: [PATCH JGIT] Minor : Make ObjectId, RemoteConfig Serializable","fromName":"Robin Rosenberg","fromEmail":"robin.rosenberg.lists@dewire.com","sentAt":"2009-02-08T02:13:21Z","receivedAt":"2009-02-08T02:13:21Z","isPatch":true,"sender":{"key":"robin.rosenberg@dewire.com","avatar":"https://avatars.githubusercontent.com/u/46357?v=4"},"body":"fredag 06 februari 2009 22:15:29 skrev Nigel Magnay:\n> Make AnyObjectId and RemoteConfig Serializable.\n> When using jgit as a library in other tools, it's helpful to be able\n> to use the nice, tested bits of jgit rather than String, but need to\n> be able to serialize them.\n\nA problem (big problem) with serialization is that it often leads to\nfragile interfaces. One might want to have precise control over\nthe serialization so a change in the implementation doesn't affect\ncompatibility. Serializing AnyObjectId should not depend on the\nimplementation de jour. Second, how do we handle subclasses?\n\nBut maybe leaving it this way would be our way of saying that\nthe interface may break at any time, promise.\n\n-- robin\n"},{"id":"103744","messageId":"320075ff0902080526g2bee8188g395397b06a0c80ee@mail.gmail.com","threadId":"17624","inReplyTo":"200902080313.21785.robin.rosenberg.lists@dewire.com","subject":"Re: [PATCH JGIT] Minor : Make ObjectId, RemoteConfig Serializable","fromName":"Nigel Magnay","fromEmail":"nigel.magnay@gmail.com","sentAt":"2009-02-08T13:26:19Z","receivedAt":"2009-02-08T13:26:19Z","isPatch":true,"sender":{"key":"nigel.magnay@gmail.com","avatar":"https://gravatar.com/avatar/d85cf38287bef3a8e4fa02358d2756d7589f8676c5eeb881ce2f6d731e4526c3?d=mp&s=160"},"body":"> A problem (big problem) with serialization is that it often leads to\n> fragile interfaces. One might want to have precise control over\n> the serialization so a change in the implementation doesn't affect\n> compatibility. Serializing AnyObjectId should not depend on the\n> implementation de jour. Second, how do we handle subclasses?\n>\n> But maybe leaving it this way would be our way of saying that\n> the interface may break at any time, promise.\n>\n\n\nWell, we can of course implement writeObject / readObject (or do so\nif/when compatibility breaks, and it's cared about)\n\nThat's how I tend to view it anyway (may break at any time) - you\ncan't just update a jar library to a significantly new version and\nexpect it all to stay compatible. Also for half my use, it's not for\npersistence, it's for transferring over the wire to a slave process.\n\nThinking a bit more clearly, I probably don't need AnyObjectId, just\nObjectId - but I've also missed RefSpec and URIish as they're used in\nRemoteConfig..\n"},{"id":"103769","messageId":"20090208191024.GA30557@spearce.org","threadId":"17624","inReplyTo":"320075ff0902080526g2bee8188g395397b06a0c80ee@mail.gmail.com","subject":"Re: [PATCH JGIT] Minor : Make ObjectId, RemoteConfig Serializable","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2009-02-08T19:10:24Z","receivedAt":"2009-02-08T19:10:24Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Nigel Magnay wrote:\n> > A problem (big problem) with serialization is that it often leads to\n> > fragile interfaces. One might want to have precise control over\n> > the serialization so a change in the implementation doesn't affect\n> > compatibility. Serializing AnyObjectId should not depend on the\n> > implementation de jour. Second, how do we handle subclasses?\n> >\n> > But maybe leaving it this way would be our way of saying that\n> > the interface may break at any time, promise.\n> \n> Well, we can of course implement writeObject / readObject (or do so\n> if/when compatibility breaks, and it's cared about)\n> \n> That's how I tend to view it anyway (may break at any time) - you\n> can't just update a jar library to a significantly new version and\n> expect it all to stay compatible. Also for half my use, it's not for\n> persistence, it's for transferring over the wire to a slave process.\n> \n> Thinking a bit more clearly, I probably don't need AnyObjectId, just\n> ObjectId - but I've also missed RefSpec and URIish as they're used in\n> RemoteConfig..\n\nHere's my two cents... we can do this, but only if we implement\nExternalizable and do the read and write ourselves so we have a\nstable format.\n\nIn the case of any of the types you are discussing there is an easy\ncanonical form for them to be written on the wire, or to read back:\n\n ObjectId - the 20 byte SHA-1\n RefSpec - the string form as it appears in the config file\n URIish - the string form as it appears in the config file\n RemoteConfig - a map of keys/values as it appears in the config\n\n-- \nShawn.\n"},{"id":"103773","messageId":"200902082045.22703.robin.rosenberg.lists@dewire.com","threadId":"17624","inReplyTo":"20090208191024.GA30557@spearce.org","subject":"Re: [PATCH JGIT] Minor : Make ObjectId, RemoteConfig Serializable","fromName":"Robin Rosenberg","fromEmail":"robin.rosenberg.lists@dewire.com","sentAt":"2009-02-08T19:45:22Z","receivedAt":"2009-02-08T19:45:22Z","isPatch":true,"sender":{"key":"robin.rosenberg@dewire.com","avatar":"https://avatars.githubusercontent.com/u/46357?v=4"},"body":"söndag 08 februari 2009 20:10:24 skrev Shawn O. Pearce:\n> Nigel Magnay wrote:\n> > > A problem (big problem) with serialization is that it often leads to\n> > > fragile interfaces. One might want to have precise control over\n> > > the serialization so a change in the implementation doesn't affect\n> > > compatibility. Serializing AnyObjectId should not depend on the\n> > > implementation de jour. Second, how do we handle subclasses?\n> > >\n> > > But maybe leaving it this way would be our way of saying that\n> > > the interface may break at any time, promise.\n> > \n> > Well, we can of course implement writeObject / readObject (or do so\n> > if/when compatibility breaks, and it's cared about)\n> > \n> > That's how I tend to view it anyway (may break at any time) - you\n> > can't just update a jar library to a significantly new version and\n> > expect it all to stay compatible. Also for half my use, it's not for\n> > persistence, it's for transferring over the wire to a slave process.\n\nOver-the wire has the same issue. Clients and servers often run with\nslightly different versions.\n\n> > Thinking a bit more clearly, I probably don't need AnyObjectId, just\n> > ObjectId - but I've also missed RefSpec and URIish as they're used in\n> > RemoteConfig..\n> \n> Here's my two cents... we can do this, but only if we implement\n> Externalizable and do the read and write ourselves so we have a\n> stable format.\n\n> In the case of any of the types you are discussing there is an easy\n> canonical form for them to be written on the wire, or to read back:\n> \n> ObjectId - the 20 byte SHA-1\n> RefSpec - the string form as it appears in the config file\n> URIish - the string form as it appears in the config file\nwith our without the password?\n\n> RemoteConfig - a map of keys/values as it appears in the config\n\nI lean toward the do it correctly side too. Don't forget a few test cases\nwith pre-recorded serializations to verify compatibility over different\nversions of jgit.\n\n-- robin\n"},{"id":"103774","messageId":"20090208194745.GA30949@spearce.org","threadId":"17624","inReplyTo":"200902082045.22703.robin.rosenberg.lists@dewire.com","subject":"Re: [PATCH JGIT] Minor : Make ObjectId, RemoteConfig Serializable","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2009-02-08T19:47:45Z","receivedAt":"2009-02-08T19:47:45Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Robin Rosenberg wrote:\n> söndag 08 februari 2009 20:10:24 skrev Shawn O. Pearce:\n> > In the case of any of the types you are discussing there is an easy\n> > canonical form for them to be written on the wire, or to read back:\n> > \n> > ObjectId - the 20 byte SHA-1\n> > RefSpec - the string form as it appears in the config file\n> > URIish - the string form as it appears in the config file\n>\n> with our without the password?\n\nWith.\n\nWe're serializing the object, we should store as much of the data\nas we have. Clients throwing this over the wire should either be\ncareful with their connection (e.g. use SSL) or be careful with\nthe data they are throwing (e.g. don't use URIish that has password).\n \n-- \nShawn.\n"}]}