Hi

I followed with interest the discussion but without many interventions. I want to explain an idea I have for supporting backward-compatibility without neither stabilizing the format nor getting the current code dirty. Maybe it's a bit crazy but I think it can be a practical solution. I would like to know your opinions.�

We can offer:

- Maintain a *compatibility package* for each released version, that can co-exist in the same image. For example Fuel1_5, Fuel1_6, etc. Obviously, the current version always has the nice clean name (Fuel).
- Provide a�facade�that works like "Fuel load: aFile asOfVersion: '1.4'" who interacts with the compatibility packages.


To generate each *compatibility package*, we rename several elements of the original Fuel released package, this way:
� * Extension methods: Append at beggining of each extension method selector a prefix. For example: #fuelAccept: --> #fuel1_6_fuelAccept:
� * Classes: Append to each one some version identifier. For example: FLSerializer --> FLSerializer_1_6
� * Methods: Fix each reference to a class or extension method selector THAT BELONGS to the package.�For example: "FLSerializer new" --> "FLSerializer_1_6 new".


I think it could be not that hard to make such renames automatically with a small tool.�Then, we can�simultaneously�maintain each *compatibility package* (Fuel1_5, Fuel1_6, etc.) when Pharo evolves:

Our Jenkins will run tests for all the compatibility Fuel packages. For example... Does�Fuel1_7 stop working in Pharo1.5? then (if it's possible) we fix it, save the monticello version and mark it�in our ConfigurationOfFuel�as "this is the stable monticello version of fuel 1.7 in pharo 1.5".


Now that I see how many lines I took to explain it, I think it's a bit�insane. I hope to read some opinions!

Bests,
Mart�n

On Thu, Oct 20, 2011 at 6:00 PM, Schwab,Wilhelm K <bschwab@anest.ufl.edu> wrote:
Mariano,

I gave you a pretty tough time :) � It appears that you understand that I did so with the best of intentions. �Thanks for listening.

One problem that I do *not* think you need to solve is that of old software talking to new software. �Someone wanting forward compatibility is probably going to use XML or something similar to get a timeless protocol that will be of necessity very simple. �A good serializer is hard to write, and forward-compatibility is probably too much to ask, particularly when efficiency is a stated goal.

A backwardly-compatible Fuel will be most welcome and useful.

Bill


________________________________________
From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Mariano Martinez Peck [marianopeck@gmail.com]
Sent: Thursday, October 20, 2011 7:00 AM
To: Pharo-project@lists.gforge.inria.fr
Subject: Re: [Pharo-project] When will Fuel file format stabilize?

On Thu, Oct 20, 2011 at 12:54 PM, Ben Coman <btc@openinworld.com<mailto:btc@openinworld.com>> wrote:
Mariano Martinez Peck wrote:
Well...thanks guys. The point is taken. Thanks Philip, Bill and all who gave feedback and suggestions. We are aware of this and we are already discussing with Martin possible solutions and analyzing all the things that has been said in this thread.
We will keep you informed.

Cheers
Just one thing I hadn't seen discussed. �Is Fuel possibly a way to exchange objects/data between users/systems ?

Yes

In which case it would have to deal with different systems having different versions of Fuel.


Exactly. It doesn't matter whether the different versions of Fuel happens in your own image or in different systems. So yes, it is the same problem.
Note this is not only a problem for Fuel, but for any serializer which does not manages full backward compatibility between versions.


--
Mariano
http://marianopeck.wordpress.com