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.