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.
Enrique