GSoC status update, week 4

Work done since last report

  • Normalization of discovered information, add protocol version info to ID alist
  • Set valid session and association types on discovery
  • Communication formats: btwoc, key-value format, with tests
  • New dependency: trivial-utf-8, for portable and fast encoding strings. Needs a changeset not merged yet into mainline, which adds support for :START and :END parameters for UTF-8-BYTES-TO-STRING, which I wrote to reduce consing in key-value format message decoding
  • Association support, unencrypted and Diffie-Hellman, 1.1-compatible

Problems

Many of code that I wrote is not testable enough. There are tests for library functions (data format etc), but main information flow is still untested. I will need to refactor the code to improve testability. This may be in line with portability work – along with true implementations of HTTP client/server stuff, dummy implementation for unit testing the logic may be provided. Also, some refactoring of biggest functions – DISCOVER and ASSOCIATE – to split it into separate, unit-testable functions might be a Good Thing.

Plans for next half week

Finishing the non-portable client:

  • Signature generation and checking for protocol messages
  • Authentication request, authentication response verification
  • HTTP-server-side flow with Hunchentoot, for indirect messages and user-visible checks (if time permits)

GSoC status update, week 3

Whew! After passing all the exams, got around to doing XRDS parsing. This turned out to be a bit complex, and now only basic XRDS support is done. What is done, however, should cover most cases. Now on to real work. I'm a bit behind the schedule already, and full Relying Party is due next week – maybe I'll need to adjust the milestones, but I still hope I can do it.

Work done since last report

  • Minor fixes to HTML discovery, better discovery workflow
  • Fixes for compatibility with Clozure CL. Clozure works really well on x86_64 Linux, and probably I'll stick to it as a default development platform (keeping testing with other implementations) – way lighter and faster than SBCL.
  • Finished discovery of XRDS document location
  • XRDS parsing

Problems

As always, things take more time than I expect. This time, I tripped over underspecified XRDS document schema in the Yadis protocol; I noticed missing parts during implementation, and had to refer to XRI Resolution specification and to examples on the Internet. What's more, OpenID 1.x support in XRDS is not specified at all, there are only some conventions and “widely used” <XRD:Type/> URIs. Seems to work on real world providers.

Plans for next half-week

  • Association support

GSoC status update, week 2

Discovery is almost finished now. HTML-based needs only tests written, and for Yadis, only XRDS analysis is left (plus tests, of course). For HTML parsing I use CL-HTML-Parse – it's light, doesn't drag any dependencies (only Allegroism it needs is the IF* macro, which is included), and handles HTML tag soup quite well.

Although I'm writing fairly separate bits of functionality, the need for some actual code architecture starts to show up. For every identity, the relying party gathers bits of information during various stages of protocol (and there are already two stages almost done), so I need to choose representation for this state. For now, to stay flexible while I need it, I made functions pass an alist with the information – initial alist is accepted by each function, and updated (possibly destructively) alist is returned. This is enough for now, and when (if) the need occurs, this shouldn't be hard to convert to proper object- or structure-based design.

Work done since last report

  • Researched and choose HTML parsing library
  • Researched public identity providers for reference identities
  • Implemented HTML discovery

Problems

Almost every public provider provides OpenID version 1. This makes compatibility with v1 much more important than I predicted, especially in the relying party. Also, many of those actually use Yadis, so its priority goes up. Yadis protocol, however, is really simple and I have most of it already done (no actual XRDS parsing yet, but this format is fairly simple and shouldn't take long).

Plans for next half week

  • Tests for HTML-based discovery and its helper functions (possible refactoring for better testability)
  • XRDS parsing & tests

Because of exams (two last finals on Monday and Wednesday, wish me luck – especially on Wednesday), I'll probably send next report on Wednesday. After it, back to regular Tuesday/Friday schedule.

Preambuła LaTeX-a

Przeniesione ze strony domowej w ramach porządków. Preambuła, której skutecznie używam z pdfplatex z PLDowego teTeX-a. Który to teTeX, swoją drogą, jest już od ponad dwóch lat martwy i zaczyna nieładnie pachnieć. Dear Lazyweb, kiedy któryś z PLDowców (osobiście się boję) ugryzie TeX Live?

\documentclass[a4paper]{mwart}
\usepackage[utf8]{inputenc}
\usepackage{polski}
\usepackage[colorlinks]{hyperref}
\usepackage{graphicx}
\usepackage{listings}
\usepackage{ucs}

\renewcommand\abstractname{Streszczenie}

\begin{document}
\begin{titlepage}
  \author{Maciej Pasternacki}
  \title{}
  \date{\today}
  \maketitle
  \vfill
  \begin{abstract}

  \end{abstract}
  \setcounter{page}{0}          % to make hyperref not barf
  \thispagestyle{empty}
\end{titlepage}


\end{document}

% Local Variables:
% Mode: LaTeX
% TeX-PDF-mode: t
% LaTeX-command: "platex"
% End:

ParenQuery

;;; parenquery -- simple chaining JS method calls for JQuery

;;; instead of manual:
;; PARENQUERY> (ps (chain foo bar baz))
;; "foo.bar.baz;"
;; PARENQUERY> (ps (chain foo bar (baz)))
;; "foo.bar.baz();"
;; PARENQUERY> (ps (chain foo (bar 1 2 3) (baz)))
;; "foo.bar(1, 2, 3).baz();"
;; PARENQUERY> (ps (chain (me.next)
;;                        (show "slow" (lambda ()
;;                                       (chain ($ this) (filter "li") (css "display" "list-item"))
;;                                       (chain ($ this) (children) (eq 0) (focus))
;;                                       (chain ($ elt) (fade-out))
;;                                       (chain ($ this) (children) (filter ".__more") (fade-in))))))
;; "me.next().show('slow', function () {
;;     $(this).filter('li').css('display', 'list-item');
;;     $(this).children().eq(0).focus();
;;     $(elt).fadeOut();
;;     $(this).children().filter('.__more').fadeIn();
;; });"

(defpackage #:parenquery
  (:use #:common-lisp #:parenscript)
  (:export #:chain))
(in-package #:parenquery)

(defun %chain-1 (first second)
  (if (listp second)
      `((slot-value ,first ',(first second)) ,@(rest second))
      `(slot-value ,first ',second)))

(defun %chain (first second &rest rest)
  (if rest
      (apply #'%chain (%chain-1 first second) rest)
      (%chain-1 first second)))

(defpsmacro chain (first second &rest rest)
  "Chain methods, as for JQuery (jquery.org)"
  (apply #'%chain first second rest))

;; This program is free software. It comes without any warranty, to
;; the extent permitted by applicable law. You can redistribute it
;; and/or modify it under the terms of the Do What The Fuck You Want
;; To Public License, Version 2, as published by Sam Hocevar. See
;; http://sam.zoy.org/wtfpl/COPYING for details.

GSoC status update, week 0.5

Common-lisp.net's Trac site is down for last few days or so, which made the work a bit harder. Nevertheless, first real code has been written. Identifier normalization seems to work. I introduced another dependency, Puri – a portable version of Allegro's net.uri. Identifiers will be internally represented by Puri URI objects; for XRI, if I get to it (support for XRI is optional), I will probably subclass URI, so that minimal API changes will be needed.

I am pondering now how to do HTML parsing for HTML-based discovery. One way would be to use CL-HTML-Parse, or pxmlutils – a port of Allegro's xmlutils. Both would require adding dependencies to the library, dragging along (in case of pxmlutils) ACL-compat Allegro portability layer. Other way would be to add HTML parsing to XMLS. This may, however, seem tricky to do right, because HTML is not as structured as XML, and there may be many corner cases (possibly unquoted tag attributes, optional close tags, and so on). I don't know at the moment, how other parsers handle misformed HTML, and HTML's corner cases. If there is no reliable parser, an interface to a tool like HTML Tidy will be needed – either FFI, or by running external program

Work done this half-week

Problems

Minor only: reviewing available servers and installing one took more time than I expected, because much of information I needed to choose (like supported OpenID version, or required libraries) was well hidden inside the software. I also spent a few hours on what turned to be a documentation error in SimpleID during its installation.

Plans for next half-week

  • Research and choose HTML parsing strategy
  • Implement HTML-based discovery
  • Write tests for discovery and HTML parsing