[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ekmi] My slip-up and an update
Hi Arshad, I don't disagree about the "overloaded" aspect of OO languages, however if overloading is such a virtue by making for more compact code then why are we creating so much buggy code? The thing I see is that documentation of what is being done is often lacking and when one uses the same command in multiple ways then it can not be self explanatory. Since programmers have shown an historical resistance to documenting their code it seems logical to create command words that are self documenting rather than count on retrospective documentation. I'll give you an example that might clarify the size of the issue of code maintenance in a real world scenario. About three years ago Yahoo wanted to refresh their authoring for the web front end and add some new functionality. It had been written in Python and when that version was to be updated all the developers who had worked of the original were no longer at the company. When they looked at the code (and Python is easy to read!) they found they did not have enough information in the code to just do a refresh and the Python developers who they had look at it said, faster to re-write from scratch. Well, they didn't have enough Python developers on staff and hiring them and getting them up to speed would stretch it out longer than they wanted to so they re-wrote the entire authoring system and all the modules in PHP! Big money costs. As I understand it using XML with properly chosen command names is to help with the documentation and maintenance of the code over time so that a change only has to be made in one place and it is clear what the command - with attached parameters - does. Overloading defeats this goal to save what? Clarity? Documentation needs? File size? Developer time? I don't think there is enough value gained for the small decrease in file size of SKSML messages to cut corners by overloading. Also, pray tell, which dialect of Klingon computerese? Shall I get together a list of the 100+ current versions in use and then we can see how crazy a language it is? ;-> Allen Arshad Noor wrote: > Allen, > > While I don't deny the confusion the English language causes, > the protocol will be implemented by software developers who > are most likely already used to Klingon :-). > > Consider object-oriented programming languages - every one of > them has overloaded methods within classes, which are a very > well understood paradigm. Far from being confusing, they are > in fact, considered a strength because it makes code compact > (so he said as he downloaded the latest version of Linux at > nearly 3+ GB ;-)). The SKSML messages are no different from > over-loaded method calls inside a class file, IMO. > > Arshad > > > Allen wrote: >> Hi Arshad, >> >> It is often best to *not* have the same name mean multiple things. >> >> For example: bear. Which am I talking about, the four footed animal or >> a burden or even meaning to move in the direction of (to bear right)? >> >> Then there are words like, there, their, and they're. Written on paper >> it is easy to see the differences but when speaking a lot of effort >> and confusion can develop. Homonyms in English and similar confusions >> make English among the most difficult of languages to achieve fluency in. >> >> The more explicit the words chosen are and the less overlap the less >> the chance of silly, but understandable, coding errors. >> >> Given that it is current estimated that ~400,000 bugs of various sorts >> and severities are being coded into programs currently but only about >> 50,000 a year are being found and eliminated, we should do our best to >> chose keyword sets that reduce the likelihood of inadvertent mistakes. >> >> Allen Schaaf - CISSP, C|EH, C|HFI, CEI >> Information Security & Risk Analyst - Business Process Analyst >> Training & Instructional Designer - Sr. Documentation Developer >> Certified Network Security Analyst and Intrusion Forensics >> Investigator - Certified EC-Council Instructor >> >> Security is lot like democracy - everyone's for it but >> few understand that you have to work at it constantly. >> >> >> >> >> Arshad Noor wrote: >>> We could do this. Under this scheme, there would be three >>> kinds of SKSML messages (actually 5, but I'm ignoring the >>> KeyCachePolicy messages for the discussion): >>> >>> 1) NewSymkeyRequest (for new symmetric keys) >>> 2) SymkeyRequest (for existing symmetric keys) >>> 3) SymkeyResponse >>> >>> Under the older scheme, there would be 2 kinds of messages: >>> >>> 1) SymkeyRequest (for new and existing symmetric keys) >>> 2) SymkeyResponse >>> >>> Personally speaking - and being a bit of a minimalist - I'd prefer to >>> stay with the 2-message protocol. Less work on the >>> spec but no change on the implementation - the server code >>> would still have to branch its code based on the request no >>> matter which way the message came. >>> >>> What do you think? >>> >>> Arshad >>> >>> ----- Original Message ----- >>> From: "Anil Saldhana" <Anil.Saldhana@redhat.com> >>> To: "Arshad Noor" <arshad.noor@strongauth.com> >>> Cc: "ekmi" <ekmi@lists.oasis-open.org> >>> Sent: Tuesday, April 15, 2008 4:27:27 PM (GMT-0800) America/Los_Angeles >>> Subject: Re: [ekmi] My slip-up and an update >>> >>> Very interesting that it took me close to a month to answer this. :( >>> >>> I was referring to the usage of GKID to indicate that the request is >>> for a new symmetric key. Why not have an explicit element such as >>> >>> ekmi:NewSymKeyRequest >>> >>> >>> >>> Arshad Noor wrote: >>>> I will expand the abbreviations to reflect the full and >>>> meaningful names, Anil. However, I don't recall the "new >>>> XML element to obtain the symmetric key". Can you refresh >>>> my memory on that? Thanks. >>>> >>>> Arshad >>>> >>>> Anil Saldhana wrote: >>>>> Arshad, >>>>> additionally as discussed at IDTrust08, I hope we can get the >>>>> expansion of the abbreviated xml element names and a new xml >>>>> element (to obtain sym key) into the drafts. >>>>> >>>>> Regards, >>>>> Anil >>>>> >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]