[cl-openid-devel] Re: message object

[Maciek Pasternacki]

Anton Vodonosov <avodonosov at yandex.ru> writes:

>>> Please provide your comments. In your blog you mentioned some MESSAGE
>>> object and I have impression that you are planing more complex
>>> refractoring.
>
>> Not really.  The OpenID protocol is concentrated on exchanging
>> messages.  The messages take different forms, external encodings and
>> transmission channels, but they’re essentially same thing all over.
>> Protocol draws a distinct line between logic (behaviour) and data
>> (message encoding, decoding, handling).
>
>> In current code, it is not so.  The message handling code is mixed
>> with logic, and done with general functions.  What I want to do is to
>> separate message-handling code to its own file, with clearly named
>> functions and accessors.
>
>> Consider the fragment from auth-request.lisp:
>
>> ,----
>> | (let ((response (direct-request (aget :op-endpoint-url id)
>> |                                 (acons "openid.mode" "check_authentication"
>> |                                         (remove "openid.mode" parameters
>> |                                                               :key #'car
>> |                                                               :test #'string=)))))
>> |   …)
>> `----
>
>> Protocol logic is mixed with low-level message mangling.  I want it to
>> look more like this:
>
>> ,----
>> | (let ((response (direct-request (endpoint-url auth-process)
>> |                                 (copy-message response
>> |                                               :mode "check_authentication"))))
>> |   …)
>> `----
>
>> This should also improve testability – it should be easy to write
>> tests for internal message API, and it would ensure there are no
>> alist-mangling-level bugs in the conversation implementation, so only
>> the behaviour would need to be tested there.
>
> OpenID messages are key-value lists, so alists are close enough...
>
> Of course we should not sprinkle the code with AGETs, but you can defun
> clearly named accessors operating directly on alists, without introducing
> a MESSAGE struct:

[cut code]

Yes, accessors working directly on alists may be good enough.  One
thing that I'd prefer about struct would be that it's possible to
modify a struct in-place, but that's a really minor issue.

You're right - I'm overengineering and optimizing prematurely.  Let's
stay with alists and just do some accessors for them.

> As I see Python's open-id message class deals with some namespaces
> for parameters, but this is for extensions as I understand and
> we do not need it now.

Namespaces are also possible with alists, sort of like what xmls does
with XML namespaces: CAR is a cons (key . namespace-uri), which is as
searchable as simple one-element key.

However, you're right that we don't need this now.

Regards,
Maciej.