"Denis Shelomovskij" <verylonglogin....@gmail.com> wrote in message news:jlkubn$k4f$1...@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.