Hi Hernan,

Could your "specific Strings" be instances of a variant of RemoteString that
compresses and decompresses? Then they will occupy less memory in your image
and it would be easier to serializer and deserialize the proxy object.

Thanks for the feedback, I also don't like the visitor interface we have for
customizations. In fact, I think it is not a visitor but a double-dispatch.
And I would prefer to merge the two hooks Mariano proposed to something
like:

String >>
fuelMapOn: aDefaultMapper (ExternalCompressor shouldCompressString: self)
ifTrue: [aDefaultMapper mapSubstitution: self by: (ExternalCompressor
compress: self)] ifFalse: [super fuelMapOn: aDefaultMapper]


Do you like more this way?

Martin


On Tue, Oct 11, 2011 at 4:10 PM, Mariano Martinez Peck <
[email protected]> wrote:

>
>
> On Tue, Oct 11, 2011 at 12:56 AM, Hernán Morales Durand <
> [email protected]> wrote:
>
>> Thanks Mariano,
>>
>> That's pretty much what I want, but... why to expose the visitor
>> interface? ;)
>>
>
> Good question. Honesty, it was the only way we have found to do it with
> Fuel. I think (but I am not sure) that one of the drawbacks of the pickle
> format is that it analysis phase (as we call it in Fuel) make some hooks
> more complicated to implement than a classic serializer.
>
>
>> Just to give a little feedback of what I have in my mind:
>>
>> mySerializer setEngine: ExternalCompressor for: ( MyClass -> #myStringIVar
>> )
>>
>>
> Well, you can also create an specific Fuel cluster for MyClass that does
> exactly that. Basically you have to create FLMyClassCluster, implement
> methods like #serializeWith: and #materializeFrom:  and there you
> serialize/materialize the specific #myStringIVar with a special way and the
> rest as normal. Then you subclass the FLDefaultMapper, say YourMapper and
> you implement #visitXXX
> Then you have to implement MyClass >> visitXXX.
> Of course, you should be able to generalize such cluster and be able to
> reuse it for different classes or instVars.
>
> I am not saying this is the best way. I am just telling you one possible
> solution you can do by extending Fuel for your needs. Of course, you may
> need to understand how Fuel works first. But of course, we can help if you
> want.
>
>
>> or
>>
>> mySerializer setEngine: ExternalCompressor for: incomingStream
>>
>> Now with machines generating daily 6 TBytes of raw data, one of the
>> keys will be data compression.
>>
>
>
> it looks like ;)
>
>
>
>> 2011/10/10 Mariano Martinez Peck <[email protected]>:
>> >
>> >
>> > On Mon, Oct 10, 2011 at 9:35 PM, Hernán Morales Durand
>> > <[email protected]> wrote:
>> >>
>> >> Is there any serializer (Fuel/StOMP/Ma object
>> >> serialization/BOSS/SRP/SIXX??) which let me attach an external
>> >> compressor/decompressor for specific Strings to the
>> >> serialization/deserialization process?
>> >
>> > In Fuel you can do:
>> >
>> > String >> fuelSubstitution
>> >       ^ ExternalCompressor compress: self
>> >
>> > String >> fuelAccept: aVisitor
>> >    ^ (ExternalCompressor shouldCompressString: self)
>> >    ifTrue: [aVisitor visitSubstitution: self]
>> >    ifFalse: [super fuelAccept: aVisitor]
>> >
>> > But the problem is that if #compress: answers an instance of String, you
>> > should be careful that if #shouldCompressString:  asnwers true to the
>> > compressed string, then you will end up in an infinitive loop.
>> >
>> > See: http://rmod.lille.inria.fr/web/pier/software/Fuel/Hooks and
>> > FLHookedSubstitutionTest
>> >
>> > I think StOMP should support this as well:
>> > http://stomp.smalltalk-users.jp/home/how-to-use-stomp/hook-methods
>> >
>> > The previous hook you let you replace the original String with its
>> > compression during serialization. Which make sense because if you are
>> going
>> > to compress it is better to do it during serialization.
>> >
>> >> With external I mean it could
>> >> be in a separate binary (I could arrange the binding though).
>> >
>> > I am not sure if I understood.
>> >
>> >
>> >
>> >>
>> >> Thanks
>> >>
>> >> Hernán
>> >>
>> >
>> >
>> >
>> > --
>> > Mariano
>> > http://marianopeck.wordpress.com
>> >
>> >
>>
>>
>
>
> --
> Mariano
> http://marianopeck.wordpress.com
>
>

Reply via email to