Maybe is too much overhead, but it is also possible to serialize an object that represents the metadata as a prefix:

FileStream forceNewFileNamed: 'demoMetadata.fuel' do: [:aStream |
aStream binary.
metadata := Dictionary with: #meta -> 5.
content := 'stuff'.
FLSerializer newDefault�
serialize: metadata on: aStream;
serialize: content on: aStream ].

FileStream oldFileNamed: 'demoMetadata.fuel' do: [:aStream |
| aMaterializer |
aStream binary.
aMaterializer := FLMaterializer newDefault.
metadata := (aMaterializer materializeFrom: aStream) root.
content := (aMaterializer materializeFrom: aStream) root ].

Martin

On Fri, Feb 10, 2012 at 8:25 AM, Igor Stasenko <siguctua@gmail.com> wrote:
On 10 February 2012 10:19, Mariano Martinez Peck <marianopeck@gmail.com> wrote:
>
>>> All you need to do is to send it a stream. If the
>>> stream is already at a certain position, it doesn't matter it will start
>>> from that position. Say you have stream where you write something first
>>> and
>>> then you give it to Fuel to serialize. The stream would be at some
>>> position
>>> different than zero. Say, at position 10. Fuel will start serializing for
>>> there. Say we have written 40 bytes. �Then, at materialization, when you
>>> give it the stream, you have to be sure to give the stream starting at
>>> the
>>> position 10.
>>
>> However if you consider Fuel "the standard file format" - this would
>> appear to be broken by people using random offsets.
>
>
>
> yes, sure. But I think its ok to fail from the serializer point of view. It
> is YOUR responsability to provide the correct streams.
>
>
>>>
>>> Fuel will load EXACTLY 40 bytes and will stop. The stream can
>>> continue....fuel doesn't care and it will store exactly when it finishes
>>> reading his own bytes.
>>>
>>> BTW, this is how some databases work. The save several serialized objects
>>> in the same stream...
>>>
>>
>> To reach for the moon... Perhaps Fuel "the standard file format" holding
>> multiple streams might be formalized by tagging different each stream with a
>> 'name' and/or a 'type' and/or 'deserializerMethod'. �The first two of these
>> might be '#fuel -> #fuelDeserializer' and '#meta->#textDeserializer'.
>
>
> I don't understand. Fuel holding multiple streams ? why? for what?
>
>>
>> �The the default Fuel system can then automatically ignore 3rd-party data.
>
>
> I want to make my point clear: Martin proposed an example that solves Yanni
> problem. If you serialize with a stream with a certain position, then you
> have to materialize it with its correct position. Dot. It is perfect that
> the materializer is broken if you do not give him the correct stream.
> Now, I DO agree that there could be another solution rather than adhoc,
> supported by fuel so that BY DEFAULT some data could be set and ignored at
> the same time...so that there is no manipulation of the srteam by the user.
>
>
no i think your approach is fine. you store what you need, and don't
care/intervene with other parts of stream,
so if user wants to add some stuff before materialized data, he free to do so.


--
Best regards,
Igor Stasenko.