D adoption prerequisites

[Unknown W. Brackets]

Perhaps that's true about the way you design web-based software, and I'm 
sorry if it is... but if you think they can be made elegantly you're 
really missing out on a large part of programming.

As for making programs more internet-ready, this is definitely useful. 
Of the programs I use daily, almost every single one of them has 
internet logic tied into it - browser, email, updates, ftp, rss news, 
live help, etc.

Of course, most desktop applications are intended to be used without 
necessary internet.  It would be ridiculous to write an archive 
extractor which:

1. Uploaded the archive, in full, to a remoting server.
2. Asked the server to extract it (on a queue.)
3. Polled for completion and progress updates.
4. Downloaded the resulting files.
5. Presented the user with the result.

If anything's worthy of www.thedailywtf.com, that would be.

Also, there's no need or gain really to making all of these things 
expose a C interface.  The trouble there is you lose things like 
templates, proper strings, etc.  I would hate to deal with such an API 
in D, and so it would have to have a wrapper.  But why?

Running on the "internet cloud" and doing remoting is not difficult. 
Writing an API for that would be easy.

However, if you think Google would've ever written their Gmail as a 
desktop client, that's just silly.  There are so many reasons they would 
never do that as their only/primary interface.  If you want Gmail on 
your desktop, take a look at Mozilla Prism.

Also, they've made the back button work, make sure you're using a modern 
browser.

-[Unknown]


Yigal Chripun wrote:
> Unknown W. Brackets wrote:
>> Count the number of GUI programs you use in a day.  For me, it's quite
>> a few... perhaps a dozen.  And you're right so far - distinct console
>> programs I directly run, on a usual day, is probably less (grep, svn,
>> and mysql my calculator mainly.)
>>
>> Now, count the number of different websites you visit in a day (the
>> majority of which are likely dynamic.)  How does that number compare?
>> Are these not programs?
>>
>> Food for thought.
>>
>> -[Unknown]
> Although you describe correctly the current situation, I must disagree
> that this situation is something we should strive towards. webapps are
> an abomination since they're a pile of hacks and band aids over a model
> that simply was never ment to be used in that way. It's like automobile
> companies will start adding features for cars so they would be usable on
> railroads. Since railroads are not suited for many small vehicles no
> matter what the feature would provide it will still remain somewhat
> strange and awkward to use.
> 
> to address the OP:
> what D needs to become mainstream is: (ordered by importance IMO)
> 1) A well defined process for standardization like RFCs (like JAVA's JCP
> or python's PEP)
> 2) the above would lead to a proper standard library instead of the
> current Tango vs. Phobos situation.
> 3) using (1) a GUI API should be defined such as to provide built-in
> remoting procedures (similar to Adobe Air) with a defined C interface
> (that's trivial in D) so that any language can be used via bindings with
> the D library, in order to write real internet applications without
> requiring a browser to run in. This means we need to have the GUI lib
> run on the client side and transparently to the user (as much as
> possible) communicates with a server side library (also with a C
> interface) that is used by the server side business logic.
> basically what I want is for thing like Gmail to become real "native"
> applications with native GUI without a need for the unnecessary browser
> chrome which frankly does not make any sense. (back button is broken,
> for example)
> The main difference from proprietary solutions like Air (except the
> proprietary part) is that Air is built so that webapps would be able to
> run on the desktop whereas I propose the opposite where desktop apps
> would run in the Internet cloud (and this functionality would be
> provided by the free D GUI toolkit instead of requiring advanced
> programming skills from the programmers).
> 
> What do you think?
> --Yigal