Re: [Gzz] Let's NOT use serialization!!!!

[Benja Fallenstein]

Tuomas Lukka wrote:

> > You think that putting client functionality in the structure without 
> > having a fallback editor is bad? You think that not being able to edit 
> > the structure because something on the Java side has changed that 
> > renders the zz structure unusable is a difficult problem? You haven't 
> > tried to load a serialized object after making a change to one of the 
> > serialized classes.
> >
> > Serialization may be a cool thing when you have stable code, but we can 
> > *not* afford not being able to make changes to our serializable classes 
> > because it would break loading serialized objects.
> >    
>
> I disagree: Sun defines very accurately what changes allow classes
> to remain stable and what changes do not. 
Of course. That's why it's ok when you have *stable* code and can afford 
not making those changes.

> And if we really want incompatible changes, all we need to do is to define
> new classes.
And keep the old classes along. The current media/impl/ classes are 
extremely bad designed, and using serialization means making it 
impossible to refactor them. I'm all against that.

> Serialization takes a lot of burden off our shoulders
a) I just spend a LOT of time getting it to work, because it makes 
things so difficult. That's not "taking burden off my shoulders" in my mind.
b) We need to maintain something else also anyway, if you haven't 
changed the earlier decision to have a human-readable format.
c) Not being able to change bad internal design decisions is something I 
don't think we need.

> and is, performance-wise,
> quite good (unlike some other designs ;),
Which one? GZZ1? No, I don't think that serializing vstreamdim 
connection diffs would have helped.

> so I'm still in favour of using it.
I'm in favor of using the YAML serializer I've just written in two days 
(as opposed to multiple weeks). Ok, it may not be so good 
performance-wise (it's using Jython because the Python YAML module is 
under a free license and the Java one isn't yet), but it's 
human-readable and independent from Java and it can cope with changes in 
our source tree without changing the serialization format and it 
guarantees that the same SliceVersion is always serialized to exactly 
the same bytes and, not least of all, it *WORKS*.

-b.