Re: [MirageOS-devel] Binary Irmin slices

[Thomas Leonard <talex5@xxxxxxxxx>]

On 19 June 2015 at 10:42, Thomas Gazagnaire <thomas@xxxxxxxxxxxxxx> wrote:
>>> It seems that Irmin.Contents.String overrides the default Tc.String
>>> serialisation with one that doesn't include the length:
>>>
>>> https://github.com/mirage/irmin/blob/ae42dab34d8451395910eb4cd534ee887a6871a5/lib/ir_contents.ml#L143
>>>
>>> Why does it do this?
>>
>> The goal is to have the file contents (once expanded on the filesystem) 
>> serialised as the raw string, not at the string with a prefix.
>>
>> While I agree that this breaks composability, I'm not sure how to fix it 
>> properly. I'd probably wrap the contents in Ir_slice.t into something that 
>> make bin-prot happy. I've moved the bug is tracked to the issue tracker[1].
>>
>> Note that the HTTP client/server code is using to_json/of_json to exchange 
>> slices, so they don't hit that bug. Would be nice to have a binary RPC 
>> backend exercising this code path. That might be an interesting project if 
>> ones want to learn about Irmin API (see [2]).
>
> The binary serialisation of slices if now fixed in irmin master. Do you have 
> anything else blocking the use of Irmin to javascript? could you update the 
> related issue[3] if that's the case?

I've updated CueKeeper to run against Irmin master, and it now works
without any hacks :-)

Thanks!

>> [1] https://github.com/mirage/irmin/issues/204
>> [2] https://github.com/mirage/irmin/issues/205
> [3] https://github.com/mirage/irmin/issues/117



-- 
Dr Thomas Leonard        http://roscidus.com/blog/
GPG: DA98 25AE CAD0 8975 7CDA  BD8E 0713 3F96 CA74 D8BA

_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel