D projects list

[Nick Sabalausky]

"Denis Shelomovskij" <verylonglogin.reg at gmail.com> wrote in message 
news:jlkubn$k4f$1 at digitalmars.com...
>I think it will be great to have a single place for all D related projects 
>so a developer can easily find what is already done
> (for an example of "I didn't now about you project" see, e.g. "Modern COM 
> Programming in D" thread), what is *planned* and what great projects have 
> already failed (and, maybe, reveal it).
>
> A draft variant of how I see such page is this with a few projects added 
> (note "Planned" tag (yes, empty for now)):
> http://deoma-cmd.ru/d/d-projects-list/
>
> Usage examples:
> * lets find a D compiler with release or beta maturity:
> http://deoma-cmd.ru/d/d-projects-list/?q=Compiler+Beta+Release
> * lets find not abandoned GUI library for D:
> http://deoma-cmd.ru/d/d-projects-list/?q=GUI+!Abandoned
>
>
> I'd like to put http://deoma-cmd.ru/d/d-projects-list/projects.js into 
> GitHub so developers can fork and edit it.
>
> I'd like to hear (but yes, I can only read, this is NG) any thoughts about 
> this idea.
>

There are already a "List of D projects" pages on the wiki: See the 
"Projects" section in the left nav panel here: 
http://prowiki.org/wiki4d/wiki.cgi  I'm sure new categories could be added 
as needed.

However, I do like the idea have having something that's searchable/sortable 
as you suggest.

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.