You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Blair Zajac <bl...@orcaware.com> on 2010/07/31 22:22:13 UTC

Re: svn commit: r981090 - in /subversion/branches/performance/subversion: include/private/svn_serializer.h libsvn_subr/svn_serializer.c

On Jul 31, 2010, at 1:28 PM, stefan2@apache.org wrote:

> Author: stefan2
> Date: Sat Jul 31 20:28:49 2010
> New Revision: 981090
> 
> URL: http://svn.apache.org/viewvc?rev=981090&view=rev
> Log:
> Introduce a simple serialization framework that simplifies and
> speeds up serialization of most data structures used by FSFS,
> for instance.

Instead of rolling another serialization in svn, what about using protobuf for C?

http://code.google.com/p/protobuf-c/

I has an Apache 2 license, so will be compatible with us.

Another one to consider is using Thrift, which writes C code:

http://wiki.apache.org/thrift/

On advantage to these serialization tools is that they are extensible, so we can always add additional fields to the serialized structs and not break binary compatibility.

Regards,
Blair

Re: svn commit: r981090 - in /subversion/branches/performance/subversion: include/private/svn_serializer.h libsvn_subr/svn_serializer.c

Posted by Stefan Fuhrmann <st...@alice-dsl.de>.
Greg Stein wrote:
> And style nit: we *never* use upper-case typedef names (and generally
> avoid hungarian notation concepts).
>   
The problem here is that gcc is very picky when it comes to
implicitly converting double pointers to const void * const *:
it tends to issue warnings. So, it takes some extra explicit
casts to silence them.

For the time being, I'm removing the typedefs and will use
verbatim casts where necessary.

-- Stefan^2.

Re: svn commit: r981090 - in /subversion/branches/performance/subversion: include/private/svn_serializer.h libsvn_subr/svn_serializer.c

Posted by Greg Stein <gs...@gmail.com>.
On Sat, Jul 31, 2010 at 18:22, Blair Zajac <bl...@orcaware.com> wrote:
>
> On Jul 31, 2010, at 1:28 PM, stefan2@apache.org wrote:
>
>> Author: stefan2
>> Date: Sat Jul 31 20:28:49 2010
>> New Revision: 981090
>>
>> URL: http://svn.apache.org/viewvc?rev=981090&view=rev
>> Log:
>> Introduce a simple serialization framework that simplifies and
>> speeds up serialization of most data structures used by FSFS,
>> for instance.
>
> Instead of rolling another serialization in svn, what about using protobuf for C?
>
> http://code.google.com/p/protobuf-c/
>
> I has an Apache 2 license, so will be compatible with us.
>
> Another one to consider is using Thrift, which writes C code:
>
> http://wiki.apache.org/thrift/
>
> On advantage to these serialization tools is that they are extensible, so we can always add additional fields to the serialized structs and not break binary compatibility.

Not to mention our skel implementation.

But the big thing here is that this serializer creates non-portable
files. IIRC, FSFS was designed to have portable files. (where
"portable" means across architectures, byte alignments, etc)

And style nit: we *never* use upper-case typedef names (and generally
avoid hungarian notation concepts).

Cheers,
-g

Re: svn commit: r981090 - in /subversion/branches/performance/subversion: include/private/svn_serializer.h libsvn_subr/svn_serializer.c

Posted by Stefan Fuhrmann <st...@alice-dsl.de>.
Blair Zajac wrote:
> On Jul 31, 2010, at 1:28 PM, stefan2@apache.org wrote:
>
>   
>> Author: stefan2
>> Date: Sat Jul 31 20:28:49 2010
>> New Revision: 981090
>>
>> URL: http://svn.apache.org/viewvc?rev=981090&view=rev
>> Log:
>> Introduce a simple serialization framework that simplifies and
>> speeds up serialization of most data structures used by FSFS,
>> for instance.
>>     
>
> Instead of rolling another serialization in svn, what about using protobuf for C?
>
> http://code.google.com/p/protobuf-c/
>
> I has an Apache 2 license, so will be compatible with us.
>
> Another one to consider is using Thrift, which writes C code:
>
> http://wiki.apache.org/thrift/
>
> On advantage to these serialization tools is that they are extensible, so we can always add additional fields to the serialized structs and not break binary compatibility.
>   
I'm happy to replace my code with any other that uses 50 LOC or less.
Do you know one ;) ?

But seriously, I probably shouldn't have mentioned FSFS in the commit
message because it obviously misled people. r981189 should make my
intentions clearer. The whole purpose of this API is to allow for efficient
implementations of svn_cache__dup_func_t, svn_cache__deserialize_func_t
and svn_cache__serialize_func_t.

-- Stefan^2.