[Bug 32125] Should support auth using captcha

[bugzilla-daemon at freedesktop.org]

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

--- Comment #33 from Dario Freddi <drf54321 at gmail.com> 2012-02-09 02:43:32 PST ---
(In reply to comment #31)
> (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
> 
> [snip]
> 
> 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?
> 

You are right indeed. Actually, it might be better to do what I am already
doing, and leave the parameter as a string in the spec, and expose an enum in
the client, just to make it easier for people implementing handlers who won't
have to parse XMPP spec this way. This should make everyone's life easier :)

-- 
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.