[Bug 32125] Should support auth using captcha

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=32125

--- Comment #31 from Simon McVittie <simon.mcvittie at collabora.co.uk> 2012-02-09 02:37:47 PST ---
(In reply to comment #28)
> > > Though, I see a potential improvement in the type of the captcha - in that
> > > case, it would be nice to have an enum with the supported types instead of a
> > > string (which would be better from a client POV)
> 
> I wasn't referring to mimetypes here, but to the "Type" parameter. XMPP
> actually does define a set of possible types of challenge (
> http://xmpp.org/extensions/xep-0158.html#challenge ), and in this case I really
> think we'd be better off with an enum

Ah, right. This is less clear-cut - in theory the set can be extended in later
versions of XEP-0158 if someone thinks of more challenges that ought to be
supported, and we might have to deal with non-XMPP protocols with challenge
types that aren't even in the XEP (in which case we could use Type =
"x-turing-test" or whatever), but extension here seems less likely than with
MIME types.

The rule of thumb that I tend to use is that if proprietary or obscure
implementations will need to extend something, then it has to be a string set;
but if extensions will only ever be made via the Telepathy spec process, then
it can be an enum. I must admit that in this case, I was partly being lazy by
letting xmpp.org maintain the registry of possible challenge types so we don't
have to :-) I expect that proprietary protocols will rarely support more than a
couple of challenge types, which they can just hard-code.

If we use an enum, then the Handler can switch() over well-known values instead
of using an if/else if... chain, which is slightly simpler... but then Gabble
would need to do a remarkably similar if/else if... chain to convert into our
enum, rather than just passing them through without understanding, which seems
non-ideal (Gabble doesn't otherwise need to understand anything about specific
challenge types).

As far as I can see, the Handler is going to need specific code for each
challenge type (or broad category of challenge types: image/video/audio/text)
anyway, so the simplification from using an enum seems pretty small?

Feel free to write an enum for the spec if you're unconvinced, though; I could
go either way.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA Contact for the bug.
You are the assignee for the bug.