D adoption prerequisites

[Yigal Chripun]

Unknown W. Brackets wrote:
> 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.

I agree. of course that would be silly. The point is to enable the
programmer to easily add internet capabilities via standard APIs and
protocols _when_the_programmer_needs_that_. If all you write is an
archive extractor by all means, just ignore the Internet-Connectivity API.
for this to work, when you do need to write a client-server program like
Gmail, the only thing you'd need to do is call a connectMe method in you
main or something to that affect, and the same GUI code you've
previously written would start magically remote calls to a server side
business logic instead of running locally.
Ideally, you could take a regular desktop application add a little
snippet of code to its initialization and it'll become client-server or
even p2p without you needing to manually serialize, deserialize and
manage the whole thing.
the other thing would be, easy installation/deployment: you click a link
in your browser and a native Gmail windows is automagically
installed/deployed/updated on the client side. the next time, you'd have
an icon in your start menu, so you wouldn't even need to find that link
in the browser.


> 
> 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?

again, the C interface is optional. If you write you code in D than use
the D API with all its neat features. The C interface is needed to make
the platform truly open. If you prefer writing your code in any other
language just use the freely available D library with you favorite
language's bindings and a C interface enables this since C is the lowest
common denominator. The Air platform for example requires me to write
flex code [or javascript with html which is wrong for real applications
IMO] and it's proprietary by nature.
a good example of this is GTK - it has bindings for many languages and
as such is very popular. compare the spread of GTK use vs other C++
based toolkits that are probably more advanced and better designed.

> 
> 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.

Mozilla prism is the exact opposite of what I'm proposing. Gmail [and
most other Google products] is written in Java. Google uses a
code-generator to produce Javascript, so even today they write it as a
desktop application. I'm sure that if you could provide the proper
conditions [i.e. a non proprietary solution based on open standards that
allows you to deploy your application automatically as described above]
the would consider to use this solution. Btw, google also provides a
gmail client for cellphones also written in Java.
Also, google wouldn't move all their code base to D just to use one
library, but if that D library had Java bindings that they could use
than this would be a different story all together.
> 
> Also, they've made the back button work, make sure you're using a modern
> browser.
> 
> -[Unknown]

of course the back button was just an example. the browser chrome still
doesn't make any sense. should I be able to bookmark a page in Gmail?
what if i deleted the message, than I'd get a dangling bookmark that
points nowhere?
Personally, I Prefer Thunderbird to read my Gmail and it provides a much
better and more intuitive UI.

--Yigal