On Apr 5, 2012 5:04 PM, "Nick Sabalausky" <[email protected]> wrote > I would suggest though, that it be separated into two main parts: > > 1. Some sort of central database with a documented, publically-accessible > machine interface, not a human interface. (And for the love of god, not > XML.) > > 2. A human-usable frontend. > > That way, alternative frontends can be created. We could even create a D > module (maybe in phobos?) to access the list. > > (IMO, that's how most web apps should work. And then backends that deal with > the same type of data should use standardized interfaces. Hell, that's how > *real* apps already work (standard file formats, network protocols, etc) - > that's how computing finally achieved interoperability decades ago, before > web apps sunk us back into the "no interoperability" dark ages again...But > now I'm ranting, I'll stop.) > > Captcha and/or user management for write-access would be built into #1, not > #2. If captcha, then a frontend would tell the backend "I want to write > access to X resource, or everything (whatever)" and the backend would send > back a captcha image. The front end would then show it to the user, and > relay the answer back to the backend. > > Actually, better yet, the backend would be user accounts only, but then > there'd be a special account for anonymous captcha users. It's be one "anon > captcha user" account for *each* frontend that wanted to allow captcha. The > frontend would then use whatever the hell captcha system it wanted and, if > the user succeeds, the frontend would transparently communicate with the > backend via its own "anon captcha user" account. And if the captcha system > used by the frontend turns out to suck, or be bypassable, or isn't even > being used by the frontend, then the backend could disable or revoke that > frontend's "anon captcha user" account. The backend could still, optionally, > provide its own "official" captcha system to any frontends that wanted to > use it
I for one, absolutely love the way you think. This is a great idea and the way it should be done. But, what is wrong with xml when used correctly.
