On 10/29/07, Emmanuel Lecharny <[EMAIL PROTECTED]> 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
