On Fri, Feb 10, 2012 at 1:19 AM, 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?
e.g. for source code. �Imagine storing Monticello packages in Fuel so that the source code is stored in the Fuel file and doesn't have to be written to the changes file. �Instead, a more powerful SourceFilesArray (actually a source file manager) can maintain a set of source files, including Fuel files, and fetch source there-from. �Hence loading is faster, and the changes file isn't polluted with code loads, containing only one's own code.
e.g. for external resources. �imagine loading a Fuel package that also contains some dlls that can be unpacked as required.
But if you choose this route let me strongly suggest you use the zip file format. �Its very useful with Monticello mcz's to be able to pick them apart using unzip.
�
�
�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.
�
Cheers
�
--
Mariano
http://marianopeck.wordpress.com