April 05, 2012
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.

-- 
Денис В. Шеломовский
Denis V. Shelomovskij
April 05, 2012
> Denis V. Shelomovskij
> I'd like to hear (but yes, I can only read, this is NG) any thoughts
> about this idea.

Looks very cool, nice job!

On 4/5/12, Denis Shelomovskij <verylonglogin.reg@gmail.com> wrote:
> http://deoma-cmd.ru/d/d-projects-list/?q=GUI+!Abandoned

A newer binding of Tk is on github although dated 2008 (not mine):
https://github.com/lysevi/dkinter
I've got an updated version that can use the newer Tk that has ttk
(more native-look widgets).

But I didn't bother with Tk much because it basically comes down to having to pass strings to a Tk eval function. For anything complicated you have to allocate a ton of strings.. Tk is probably best left for use with scripting languages imo.
April 05, 2012
"Denis Shelomovskij" <verylonglogin.reg@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.


April 05, 2012
On Thursday, 5 April 2012 at 21:02:15 UTC, Nick Sabalausky wrote:
> I would suggest though, that it be separated into two main parts:

kill both birds with one web.d.
April 05, 2012
On Apr 5, 2012 5:04 PM, "Nick Sabalausky" <a@a.a> 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.


April 05, 2012
"Kevin Cox" <kevincox.ca@gmail.com> wrote in message news:mailman.1385.1333660352.4860.digitalmars-d@puremagic.com...
> On Apr 5, 2012 5:04 PM, "Nick Sabalausky" <a@a.a> wrote
>>
>> [...]
>
> I for one, absolutely love the way you think.

Really? That's pretty uncommon ;) Most people usually just think I'm nuts!

> But, what is wrong with xml when used correctly.
>

Well, it's technically usable, but it's overrated: It's overly-verbose and over-engineered. It seems simple at a glance, and it really *should* be, and *could* have been, but there's a lot of unnecessary complications if you really dig into *proper* XML. I mean heck, just look at the spec: I know formal standards naturally tend to be big and pedantic, but for something as conceptually simple as XML appears to be, it's waaay out of control. Even as a big super-formal standard, XML *still* shouldn't be *that* complex.

JSON is somewhat better, and YAML better still. But protocol buffers are vastly superior IMO.


April 05, 2012
On Thursday, 5 April 2012 at 20:12:39 UTC, Denis Shelomovskij wrote:
> 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/

Well, lists have been attempted (Dsource is a good example), but you are obviously looking at something with good filtering. This is good.

There is also work for a package management system Orbit, this likely needs similar functionality.

Namely, some one needs to build this stuff, it isn't that they aren't wanted.
April 05, 2012
I think this thread misses the key problem with anything like this.. how to curate the list.  How will it be kept current?  What's the definition of abandoned?  Etc, etc.  The presentation and storage formats are almost irrelevant as they're the easiest part of the problem.

On Fri, 6 Apr 2012, Denis Shelomovskij wrote:

> Date: Fri, 06 Apr 2012 00:13:04 +0400
> From: Denis Shelomovskij <verylonglogin.reg@gmail.com>
> Reply-To: digitalmars.D <digitalmars-d@puremagic.com>
> To: digitalmars-d@puremagic.com
> Newsgroups: digitalmars.D
> Subject: D projects list
> 
> 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.
> 
> -- 
> ????? ?. ???????????
> Denis V. Shelomovskij
> 
April 05, 2012
On Thursday, April 05, 2012 17:48:05 Nick Sabalausky wrote:
> "Kevin Cox" <kevincox.ca@gmail.com> wrote in message news:mailman.1385.1333660352.4860.digitalmars-d@puremagic.com...
> 
> > On Apr 5, 2012 5:04 PM, "Nick Sabalausky" <a@a.a> wrote
> > 
> >> [...]
> > 
> > I for one, absolutely love the way you think.
> 
> Really? That's pretty uncommon ;) Most people usually just think I'm nuts!

Maybe he just really likes nuts? ;)

- Jonathan M Davis
April 05, 2012
"Jonathan M Davis" <jmdavisProg@gmx.com> wrote in message news:mailman.1392.1333667746.4860.digitalmars-d@puremagic.com...
> On Thursday, April 05, 2012 17:48:05 Nick Sabalausky wrote:
>> "Kevin Cox" <kevincox.ca@gmail.com> wrote in message news:mailman.1385.1333660352.4860.digitalmars-d@puremagic.com...
>>
>> > On Apr 5, 2012 5:04 PM, "Nick Sabalausky" <a@a.a> wrote
>> >
>> >> [...]
>> >
>> > I for one, absolutely love the way you think.
>>
>> Really? That's pretty uncommon ;) Most people usually just think I'm nuts!
>
> Maybe he just really likes nuts? ;)
>

Mmmm, pistachios... </homer-voice>


« First   ‹ Prev
1 2 3
Top | Discussion index | About this forum | D home