Other serialisation formats -- SIXX serialisation format, JSON, Fuel?

I have started using Fuel and Ma Serializer to store PasteUpMorphs
stored in a project. Actually it is a collection of PastUpMorphs used
as a slide show. I used as well SIXX for some tests.

It is possible to keep all the serialization packages in the same image.

Fuel and Ma Serializer work fine so far to save and restore
PasteUpMorphs (with content).
To use SIXX I had to go for a description and then restore from the
description. Interestingly SIXX was about as space efficient as the
other ones if I used compression on the the resulting file. As SISS is
modeled after SIXX the result is probably the same (I did not verify
this).

For the tests I did so far Ma Serializer was more space efficient. And
the claim is that it spans versions wherase Fuel description
explicitly states that it does not.

There is a need to agree on some test cases and criteria.

It is as well worth considering supporting different formats.

The API to do so is very thin.

E.g. for the Fuel test to restore the slide collection I just had to do.

slides := FLMaterializer materializeFromFileNamed:
'/home/user/sq5.1test-Fuel/documentation/Kopie_Lit_01.FL'.

slides reverseDo: [:s | s openInWorld]

--Hannes

On 9/1/16, H. Hirzel <[hidden email]> wrote:
> To widen the discussion.
>
> I think there was no discussion yet if the serialisation format should
>
> a) be a binary format
> b) a text format
> c) or that we need both.
>
> The prominent use case is saving and loading of projects, see thread
>
> 'Vaidotas, Squeak 5.1 saving of Morphic projects is broken'
>
> and the SISS thread.
>
> Speed of course is an issue.
> But then as well portability between different versions of images.
>
> If the question is put as
>
> Which serialisation format should succeed image segments then then the
> choice is probably limited to
>
> - Fuel
> - Ma Serializer
>
>
> On 8/31/16, Chris Muller <[hidden email]> wrote:
>> I would, of course, love for Ma Serializer to be considered.  Its
>> mature and proven, and has a lot of hooks and I just know the scrutiny
>> and brilliance of this community would benefit it tremendously, and
>> since Magma uses it, would make Magma fundamentally better, too.
>>
>> The Fuel hysteria appears to have already garnered everyone's vote
>> before I saw this thread to get myself on the ballot..    I once took
>> at look at trying to use Fuel for Magma, but its much too limited (and
>> not nearly as much faster than Ma Serializer as reported in the Fuel
>> paper).  Its is good for UC1) Save an object and UC2) Load an object,
>> but not much else.  :(
>>
>> On Wed, Aug 31, 2016 at 6:40 AM, Eliot Miranda <[hidden email]>
>> wrote:
>>>
>>>
>>> On Aug 31, 2016, at 11:14 AM, Bert Freudenberg <[hidden email]>
>>> wrote:
>>>
>>> On Wednesday, 31 August 2016, H. Hirzel <[hidden email]> wrote:
>>>>
>>>>
>>>> We might consider JSON or Fuel might as well options for a format to
>>>> save projects (with ImageMorphs, Browsers, Workspaces, BookMorphs for
>>>> example).
>>>
>>>
>>> If someone wants to take a serious look I'd suggest Fuel. Being a
>>> replacement for ImageSegments was one of its design goals, if I remember
>>> correctly.
>>>
>>>
>>> +1.  It also has a very performant architecture.  It is very similar to
>>> VW's
>>> parcel format which priced to be significantly faster than other formats
>>> at
>>> PPD.
>>>
>>>
>>> - Bert -
>>>
>>>
>>>
>>>
>>>
>>
>>
>