On Sun, Oct 16, 2011 at 1:20 PM, Philippe Marschall <kustos@gmx.net> wrote:

On 15.10.2011 15:06, Martin Dias wrote:
> I like the ideas of Stef and Ben of loading multiple fuel versions at
> the same time. Do you know something done in that sense?
>
> Mart��n
>
> On Sat, Oct 15, 2011 at 7:09 AM, Mariano Martinez Peck
> <marianopeck@gmail.com

> <mailto:marianopeck@gmail.com>> wrote:
>
>
>
> �� On Sat, Oct 15, 2011 at 11:49 AM, Philippe Marschall
> �� <kustos@gmx.net

> �� <mailto:kustos@gmx.net>> wrote:
>
> �� On 11.10.2011 21:51, Mariano Martinez Peck wrote:
> �� >
> �� >
> �� > On Tue, Oct 11, 2011 at 8:55 AM, Philippe Marschall
> �� > <philippe.marschall@netcetera.ch
> �� <mailto:philippe.marschall@netcetera.ch>
> �� >

> �� <mailto:philippe.marschall@netcetera.ch

> �� <mailto:philippe.marschall@netcetera.ch>>>
> �� wrote:
> �� >
> �� > �� On 10/08/2011 10:42 PM, Mariano Martinez Peck wrote:
> �� > �� > s
> �� > �� >
> �� > �� >>>
> �� > �� >>> This is IMHO more than necessary for Fuel to become a
> �� production
> �� > �� ready
> �� > �� >>> serializer and I'd say Fuel is now "old enough" to
> �� become such :)
> �� > �� >>
> �� > �� >> Yes.
> �� > �� >> Now what I would love is that even if fuel changes that the
> �� > �� evolution of
> �� > �� >> information
> �� > �� >> is taken into account because like that it will be
> �� exercised for
> �� > �� real.
> �� > �� >>
> �� > �� >>
> �� > �� > No, that's impossible, and if posible, it is not worth it.
> �� > �� Migrating from an
> �� > �� > old format to a new one is extremelly complicated and
> �� innecessary. The
> �� > �� > easiest way to solve this is to take the correct version
> �� of Fuel,
> �� > �� > materialize the graph from the stream, load new version
> �� of Fuel, and
> �� > �� > seriaize it again. That the easiest, more secure, and
> �� more practical
> �� > �� > approach I can see.
> �� >
> �� > �� That is horribly na��ve an excludes fuel from a lot of use
> �� cases. You
> �� > �� can't use fuel for "archiving" objects outside of the
> �� image because you
> �� > �� will never know whether you will be able to read them in
> �� again because
> �� > �� the format changes. You will always need to have "live"
> �� ones in the
> �� > �� image.
> �� >
> �� >
> �� > No. That's incorrect. You won't be able to do that ONLY if you
> �� update
> �� > Fuel to a new image that breaks format.
> �� > You can still continue to use the same version and you will
> �� never have
> �� > that problem. So, again, why you need to update Fuel?
>
> �� Because it's old software. Bugs may not get fixed. It may not
> �� work in
> �� newer Pharo versions. I may have dependencies on other libraries
> �� that
> �� may require a new version of Fuel. You name it.
>
>
>
> �� I understand. What I mean is that depending on the changes and the
> �� amount of work, you can just adapt Fuel to new versions of Pharo but
> �� without changing its format.
> �� I mean....say you were in Fuel 1.4. You don't need to move to Fuel
> �� 1.8 just because. You can just try to fix 1.4 to make it work in
> �� latest pharo.

Oh yeah sure, I can always fork Fuel and maintain it myself. That's
exactly what I don't don't want to do.

Well...the thread is starting to be offtopic. I will try once again to explain MY thoguhts:

A serializer can evolve in 2 ways: just changing or changing but also making previous versions incompatible.
At the same time, a serializer can be in development stage or in maintenance. Fuel is still in development. Even if it is stable in the sense there are no bugs, we are still developing it and we will continue to improve it and change its format. ReferenceSteam is finish, its in maintenance.

Now..as an example, Fuel 1.6 is working in Pharo 1.2, 1.3 and 1.4.�� THat is, 3 mayor versions of Pharo without changing even Fuel version. Isn't that enough for you? do you want to be able to materialize a graph 10 years after with the same version of Fuel? well, then you have to update Fuel to latest version of pharo without changing its format. And that is exactly what Pharo team does with ReferenceStream. Why? because it is just in the image, so if there are methods renamed or removed, ReferneceStream is immediately fixed. What's the difference with Fuel? that it is not in the core, hence not updated by them.��

��

> �� That's EXACTLY what we do with ReferenceStream and friends. The only
> �� difference is that the Pharo team does that because it is in the core.
> �� But yes, it may happen that ideed you will require a new version of
> �� Fuel.

What�� What's the advantage of Fuel over ReferenceStream again?

I don't understand your question, but if you want to know the advantages of Fuel over ReferenceStream, read the Fuel paper.

��

> �� > Why SmartRefStream does not have this problem? ��because it hasn't
> �� > changed in the last 10 years.
> �� > So..do the same, take an specific Fuel version and keep it for
> �� 10 years.
> �� > Just update it to make it work in Pharo without changing the
> �� format and
> �� > you are done.
> �� >
> �� >
> �� >
> �� > �� That means you can't use fuel for anything Monticello
> �� related because
> �� > �� you may never be able to load those versions in again
> �� because the file
> �� > �� format has changed in the mean time.
> �� >
> �� >
> �� > I guess that in the end, if someone can really do something for
> �� > Monticello on top of Fuel it will be like 2 years from now,
> �� and at some
> �� > point Fuel format will be stable.
> �� > And as Stef says...you always have the code there in case of
> �� problems.
>
> �� Monticello is just an example for a case where I want to store
> �� objects
> �� outside of the image.
>
>
> �� Well, then you can just wait until we finish. Give us one year more.
> �� Instead of doing 1-year-long releases, we like to do 3 months
> �� releases.
> �� But again, that doesn't mean you have to update...

So you're saying I shouldn't use Fuel?

If you plan to serialize now and materialize in 10 years with a new Pharo image and you are not willing to update Fuel to make it work in that Pharo image, then yes, don't use it.
Use ReferenceStream and hope that Pharo team keep it updated for 10 years without changing its format.

��

Cheers
Philippe