Re: [Jsynthlib-devel] RE: Jsynthlib-devel digest, Vol 1 #180 - 1 msg

[Joe E. <jo...@em...>]

Gor...@ne... wrote:

>Not meaning any disrespect or anything, but what is the goal of
>saving in XML format?
>  
>
The main goal is to switch to something *other* than what we have now 
(which I'll get to), and XML seems like as good of an option as any.

The reason to switch from the current format is related to the 
refactoring goal that some of the developers (including myself) have. 
Basically, those developers feel that having all of the classes in 
core.* is (at a minimum) ugly and confusing to new developers since it's 
not clear what classes deal with which functions of JSL (as opposed to 
having classes in packages like org.jsynthlib.midi, 
org.jsynthlib.library, org.jsynthlib.config, etc). In addition, it's 
probably confusing to *old* developers, too, in the sense that having 
everything in core.* lets them code classes with looser encapsulation 
(which I usually regard as a bad thing) than they'd be forced to with 
the classes spread over more packages.

Okay... got all that?

Now, the *problem* is, we can't move forward with the refactoring. Even 
though Eclipse, among other IDE's, could allow any of us to do it in 
about an hour, it would break all of the existing patchlibs because.... 
(drumroll, please...)    the current patchlib format uses Java 
serialization. So, whole objects (in our case, JSL's JTableModel in 
which it stores all of the patches/banks of a patchlib) are just dumped 
to a file (into which the Java serialization mechanism also stores the 
classnames of the objects). Because of this, if we move any of the 
classes like AbstractLibraryFrame or IPatch or Patch somewhere other 
than core.*, it will probably cause the serialization code to throw an 
exception because it can't find the classes anymore.

The serialization has already caused problems in the past. (And I'm a 
little foggy on this one so, if I don't have it completely right, 
forgive me). If you look at some of the core.* classes, you'll see that 
someone had to hard-code serialization ID's into some of the classes 
because a change was made to that class which changed Java's 
auto-generated serial number for it. I wasn't around when this took 
place, but that's the story I heard.

So... there seemed to be a consensus that, in order to move forward with 
the refactoring (ie, moving all of the classes into a more-sane package 
structure), we had to move away from the serialized patchlib format. 
So... what do we move to? XML seemed to be a reasonable choice because 
there are already plenty of tools which handle all of the checking of 
validity/well-formedness and which make it easy to read/write the 
documents. Lastly, it's both backward and forward compatible. Within 
certain limitations, we could make ammendments to the XML patchlib 
format such that:
  1 - Someone with a copy of JSL which uses the original XML format 
would be able to read/use the newer XML patchlib files, and
  2 - Someone with a newer copy of JSL which used the latest format 
would be able to read/use the older XML patchlib format files.

Is that reason enough? :)

- Joe