GSoC Status Update, week 12½ (final)
Seriously, where did this half a week come from? I can understand periods of time disappearing, but half a week appearing out of nowhere is something new to me. But I won't complain – extra time is good. ;)
Pencils down now. Of course, project continues, but evaluations for Google will be based on what is done now, thus gsoc_2008_pencils_down tag in darcs. The second tag is much nicer, it's 1_0_rc1. I think I got to a passable 1.0 version now. It may need some more unit tests (as always), documentation polishing, most probably there may still be bugs, and I don't want to call it a full 1.0 version before using the library in some actual application. Besides that, feature-, documentation- and API-wise all seems to be complete.
Work done since last report
- Fixed some bugs, esp. portability to other Lisps
- Some polishing (dropping unnecessary format string/argument pairs, renaming accessors, dependency updates, things like this)
- Documentation!
- Some unit tests (not that much)
Problems
This “Problems” section will list what doesn't seem to be complete after the “pencils down” timestamp rather than current problems. Completing those will go into 1.1:
- Unit tests don't cover much of actual protocol code. Not sure exactly how to do this, and whether it's worth to do it. We'll see.
- YADIS (#7), and Relying Party discovery (#13). Yadis support should be moved to a separate library, and used for discovering Relying Party return_to endpoints.
- Random number generation (#14). The rfc1750 should be implemented as a separate library atop Ironclad for secure pseudo-random number generation. Currently plain
CL:RANDOMis used, which is not acceptable for security-sensitive deployments. - With regard to original proposal, most of portability has been deemed actually irrelevant. Web server portability has been achieved, web client and storage portability has been dropped. All storage is in-memory and that's enough (keeping user data is responsibility of library's user, and associations / nonces/ authentication processes can be kept in memory).
- API for 1.0 was deliberately kept as simple and small as possible to have any functioning relying party or provider. Intended side-effect is that it may not be flexible enough to support users' actual needs. I decided to keep API small and simple, and to extend it to actual users' requirements, instead of trying to get most comprehensive API ever. Not actually a problem, but connected with above (when need for HTTP client or storage portability will actually arise, it will be added).
- Relying Party and Provider are not separate systems; the specific RP/OP code is small, and the required libraries are common anyway. It will most probably stay this way.
- Logging. As for now, logging is responsibility of CL-OpenID user. Maybe it would be useful if library itself was able to log events. Not before 1.1, though.
Plans for future
Similarly to problems, final report's plans are also referring to the general future instead of next half-week. I intend to support the library, and use it in my own Web projects. Current state of code is labeled 1.0rc1; after some discussions with users, using CL-OpenID in own code, I will label it 1.0. It will need to wait a bit, as bugs and omissions will surely manifest. I expect to have final 1.0 in September. After that, issues listed in “Problems” section are more of a TODO list for 1.1. When that is done, some actual deployments will be already done, and I will be able to tell whether it's maintenance phase already, or should the development continue to 1.2 or 2.0.
So, that's it. Pencils down. Planet PLD and other planet spammage by these reports will cease (contrary to some comments, there seems to be no spammage anywhere else since about two weeks, when I stopped redirecting those posts to techblog; if I'm wrong, please correct me even if it's too late). Now, off to announce 1.0rc1 to the world!