Serialization framework future

[Dmitri Pal]

On 05/30/2012 05:31 PM, ghudson at mit.edu wrote:
> I'm working on implementing gss_import_cred/gss_export_cred, and for
> that I'll need a way to serialize a credential (the TGT credential
> from a memory ccache).
>
> This leads me to think about the state of our serialization framework,
> which I'm not fond of for a number of reasons: the coding style is
> rather divergent from our current practices, it uses krb5_* symbol
> names even though it's not part of the public API, and everything goes
> through a table lookup of KV5M_* values for no reason (which adds
> artificial exception cases for sizing and serializing).
>
> As far as I can see, the only public interfaces to this stuff are the
> gss_import/gss_export APIs, so we have a lot of freedom to change
> this.  Options I can see for serialization are:
>
> 1. Leave it alone (just add a cred serializer without changing
> anything about the code).
>
> 2. Alter the coding style and symbol names without changing the
> design.
>
> 3. Rewrite it more aggresively (eliminate the magic number table and
> just having size/serialize/unserialize functions for each type).
>
> 4. Borrow the krb5_storage framework from Heimdal.
>
> Heimdal's krb5_storage is a readable/writable buffer with a few
> different back ends (fixed memory, resizable memory, and file
> descriptor; it has an internal vtable with fetch/store/seek/trunc/free
> operations), along with some functions for marshalling and
> unmarshalling krb5 data types to or from a buffer.  It's maybe a
> little over-engineered for this specific purpose, but it could come in
> handy for other purposes, and could perhaps replace k5buf and asn1buf
> in the future.  We would have to alter the code somewhat to fit, so it
> wouldn't be a simple drop-in.
>
> Opinions?
> _______________________________________________
> krbdev mailing list             krbdev at mit.edu
> https://mailman.mit.edu/mailman/listinfo/krbdev
>
>
If the risk and the cost of making it better/cleaner and more
maintainable are low I would say 3 or 4

-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IPA project,
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/