directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Zheng, Kai" <>
Subject RE: A default backend based on Google FlatBuffers?
Date Sat, 19 Sep 2015 11:55:24 GMT
Thanks Emmanuel for the feedback.

Yeah, it needs encoding, that means the flatbuffers format should be used to store entries.

It does avoid decoding data, because it operates directly on the binary data. In details,
one may mmap loads the content from a file and gets a bytebuffer. Then all the entries can
be looked up directly on the bytebuffer. As you said one may find an entry efficiently, I
thought a mapping from key to the start address of the corresponding object would be required.
Given the start address of the object, then all the fields of the object can be directly retrieved
without any decoding.

Please take your time to read the doc, I thought it's interesting. Hope it helps in our projects.

You're right, better to have some prototype. Code talks. I will have some try.


-----Original Message-----
From: Emmanuel Lécharny [] 
Sent: Saturday, September 19, 2015 2:55 PM
To: Apache Directory Developers List <>
Subject: Re: A default backend based on Google FlatBuffers?

Le 19/09/15 02:05, Zheng, Kai a écrit :
> Hi,
> How would you like google flatbuffers? It's performance is super cool! It eliminate decoding
at all! I'm thinking about a built-in and default backend for Kerby based on the format. Existing
backends are only suitable in some cases, but a default backend like kdb used in MIT KDC would
be desired for a production deployment for Kerby KDC in future. Mention it in case it's also
useful in some other components.

I still don't get what it brings. At some point, you still have to serialize/deserialize data,
and if you want to be efficient, you need a way to find data efficiently (ie, without parsing
all the file).

Give me a couple of days to look at the documentation. At some point, some prototype would
certainly be useful.

View raw message