directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Enrique Rodriguez" <>
Subject Re: [Kerberos] Ticket structure
Date Sun, 04 Nov 2007 02:13:33 GMT
On 10/29/07, Emmanuel Lecharny <> wrote:
> ...
> Now, I'm wondering if it's a good thing to also provide the accessors to
> this unsealed value in the Ticket class. I would favor this kind of access :
> ticket.getDecryptedTicket().getClientAddresses()
> instead of :
> ticket.getClientAddresses()
> At first sight, it seems that the second form is lighter, but it has the
> big inconvenient to duplicate the accessors : you already have a
> getClientAddesses() method in the EncTicketpart class.
> ...

I think the delegate methods are a better API.  Certainly the methods
are duplicated, but you can auto-generate these methods in an IDE
(assuming logical names) and also you can make the methods on the
EncTicketPart package-scoped.  Developers would work only with the
Ticket class and we'd throw IllegalStateException on methods when the
Ticket is not yet decrypted.

> I like to have basic structure being as close as possible to the ASN.1
> names, because it helps people who read the RFCs to get a quick
> understanding of the code. But I also have some concerns when it comes
> to implement, say, 'sname'. Ticket.getSName() is really not the best
> method call I ever saw, compared to Ticket.getServerName().

I totally agree and it gets worse.  'sname' at least follows a bit of
a convention with 'cname', 'srealm', and 'crealm'.  Contrast this with
'from', 'till', 'rtime', 'authtime', 'starttime', 'endtime', and
'renew-till'.  I understand your reasoning, and it's noble, but I
recall my early days with Kerberos when, for the longest time, I
misinterpreted 'rtime' on a regular basis.

> I don't know. The idea is to discuss all those kind of questions in
> order to share the ideas and have the best solution, as a community.
> If you tell me that getSName() is far from being perfect, I will just
> switch back to the previous name :) (anyway, I don't like this name
> either... )

'getSName()' is far from perfect.


View raw message