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. Regards, Kai -----Original Message----- From: Emmanuel Lécharny [mailto:[email protected]] Sent: Saturday, September 19, 2015 2:55 PM To: Apache Directory Developers List <[email protected]> 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.
