Note: This is is the original version of a message I posted to the dotLRN forum at http://www.openacs.org.
I have been hearing a lot of questions about what OKI is and how to make sense of it in the dotLRN context.
First off, the authoritative place to find out about OKI is the OKI web site. Quoting the General Overview on specifications page, "The OSID's are an abstraction layer between the programmer and the enterprise infrastructure systems of his or her campus".
If you hunt around and download the source code from http://sourceforge.net/projects/okiproject you'll discover that the OKI is implemented in Java. Hmm, does this mean that the only way to be OKI-compliant is to program in Java? Not necessarily. In face-to-face meetings and perhaps also on the web site (I can't seem to find the URL now), the OKI team has stated that their ideas have always been larger than Java, but for sake of concreteness they had to build in a specific language.
What would it mean to be "OKI-compliant" in a non-Java system? Here is my take. There are parts of OKI are tied to the runtime environment and parts that are not. In a world with multiple runtimes, the OKI idea gets diluted because my Tcl code will not be "plug-and-play" with your Perl code or someone else's Java code. Fine. How about within a runtime? Can we benefit from standard interfaces that everybody follows? Absolutely. That's what OpenACS Service Contracts are all about.
So if we use Service Contracts everywhere, would that make us OKI-compliant? This is where things get interesting. My is answer is a qualified "yes". Because the OKI-team has been largely mum on non-Java implementations, there is probably room to establish ideas about what it would take for a non-Java version to get the OKI seal of approval, and then work with or lobby OKI to grant that seal. Whether or to what extent this community wants to undertake that work is up for debate. That's part of the reason for this post.
To make things a little more concrete, let's take a closer look at what OKI is about and consider the character of an implentation that might win approval:
| OKI idea | Hypothetical dotLRN incarnation | Depends on runtime? |
|---|---|---|
| A conceptual notion of architecture. Example: Access to authentication databases should be standardized; we will have an Authentication API. | dotLRN will have an Authentication API | No |
| A conceptual notion of what APIs apis will look like. Example: Users and groups will be encapsulated in an Agent class that contains a getDisplayName() method for accessing the display name of the user or group, and a getId() method for accessing the unique ID. Identities will be obtained by calling the authenticate() method of the AuthenticationManager class." | dotLRN will have an Agent data structure with DisplayName and Id members. dotLRN will have an AuthenticationManager service contract with an authenticate operation. | Sort of. We don't really have "classes" in Tcl, so we'll have to approximate them with data structures (e.g. Tcl arrays). We don't have "interfaces" either but service contracts are reasonably close. |
| There will be published, standard language-specific interfaces for the APIs. Implementors will build various implementations for applications and frameworks to consume. | There will be published, standard OpenACS Service Contracts for the APIs. Implementors will build various implementations for applications and frameworks to consume. | Yes. We can only inter-operate within the OpenACS realm. |
Now, I think we'd all agree that following the OKI ideas in some form or another is a Good Thing. Hence we have the great work Collaboraid has done on the external authentication spec. The open questions are, whether to spend the energy to establish an interpretation of OKI-compliance for dotLRN, and then having that, to determine on a domain by domain basis whether and how to work toward that compliance.
If you made it this far, do you buy the above? If so, do you think we should invest in working with/on OKI? What about authentication specifically? With or without OKI, we have a good, mature spec. IMHO we shouldn't let it get bogged down. At the same time, we may be able to reach compliance fairly easily (that remains to be seen). If we could reach compliance with little additional effort, say with a few changes of variable names, would it be worth it?.