I've stumbled upon the following: http://rswt.sourceforge.net

This is a port of SWT to run on top of RMI. The idea is that you use the same SWT API only you can put your GUI on a different machine than the application logic. the GUI will be be run natively on the client machine via the native SWT libs. There are only two objects that manage this connection and everything else remains the same.

My question is how much work would it take to port this functionality to DWT? Does it require to also port the RMI APIs or is there a simpler way?

Yigal Chripun schrieb:
> I've stumbled upon the following:
> http://rswt.sourceforge.net
> 
> This is a port of SWT to run on top of RMI. The idea is that you use the
> same SWT API only you can put your GUI on a different machine than the
> application logic. the GUI will be be run natively on the client machine
> via the native SWT libs. There are only two objects that manage this
> connection and everything else remains the same.
> 
> My question is how much work would it take to port this functionality to
> DWT? Does it require to also port the RMI APIs or is there a simpler way?

The link above is not working for me. Is the project still alive?
On sf.net the latest changes are from 2003.

Frank Benoit wrote:
> Yigal Chripun schrieb:
>> I've stumbled upon the following: http://rswt.sourceforge.net
>>
>> This is a port of SWT to run on top of RMI. The idea is that you use the same SWT API only you can put your GUI on a different machine than the application logic. the GUI will be be run natively on the client machine via the native SWT libs. There are only two objects that manage this connection and everything else remains the same.
>>
>> My question is how much work would it take to port this functionality to DWT? Does it require to also port the RMI APIs or is there a simpler way?
> 
> The link above is not working for me. Is the project still alive? On sf.net the latest changes are from 2003.
> 

try this:
http://rswt.sourceforge.net/quickstart.html

there is only one version circa 2003.

Yigal Chripun schrieb:
> Frank Benoit wrote:
>> Yigal Chripun schrieb:
>>> I've stumbled upon the following:
>>> http://rswt.sourceforge.net
>>>
>>> This is a port of SWT to run on top of RMI. The idea is that you use the
>>> same SWT API only you can put your GUI on a different machine than the
>>> application logic. the GUI will be be run natively on the client machine
>>> via the native SWT libs. There are only two objects that manage this
>>> connection and everything else remains the same.
>>>
>>> My question is how much work would it take to port this functionality to
>>> DWT? Does it require to also port the RMI APIs or is there a simpler way?
>> The link above is not working for me. Is the project still alive?
>> On sf.net the latest changes are from 2003.
>>
> 
> try this:
> http://rswt.sourceforge.net/quickstart.html
> 
> there is only one version circa 2003.

to me, it looks like a lot of work.
But it is not directly related to SWT. It is about implementing this RMI, reflection information and code generation.
Interesting questions are virtual function calls, GC, synchronisation, performance.
If that all works, it could be used with every library.

What i don't understand is.. why?
Do you want the remote thing? Or do you see this as another - perhaps more easy - way of porting SWT?

Frank Benoit wrote:
> Yigal Chripun schrieb:
>> Frank Benoit wrote:
>>> Yigal Chripun schrieb:
>>>> I've stumbled upon the following: http://rswt.sourceforge.net
>>>>
>>>> This is a port of SWT to run on top of RMI. The idea is that you use
>>>> the
>>>> same SWT API only you can put your GUI on a different machine than the
>>>> application logic. the GUI will be be run natively on the client
>>>> machine
>>>> via the native SWT libs. There are only two objects that manage this
>>>> connection and everything else remains the same.
>>>>
>>>> My question is how much work would it take to port this
>>>> functionality to
>>>> DWT? Does it require to also port the RMI APIs or is there a simpler
>>>> way?
>>> The link above is not working for me. Is the project still alive? On sf.net the latest changes are from 2003.
>>>
>>
>> try this:
>> http://rswt.sourceforge.net/quickstart.html
>>
>> there is only one version circa 2003.
> 
> to me, it looks like a lot of work.
> But it is not directly related to SWT. It is about implementing this
> RMI, reflection information and code generation.
> Interesting questions are virtual function calls, GC, synchronisation,
> performance.

if it works in Java why shouldn't it work in D?
> If that all works, it could be used with every library.

RMI is an Independent remoting/synchronization API for Java. I think Tango has something similar albeit Tango's synchronization is explicit IIRC.

> 
> What i don't understand is.. why?
> Do you want the remote thing? Or do you see this as another - perhaps
> more easy - way of porting SWT?

I want the ability to have a native GUI client connect to a server that
provides a service (Wweb browser, mail, Gmail, etc). basically all those
"web applications" like Gmail could be replaced by this.
I see it as a very powerful feature, especially given that in D it would
be trivial to use (No JVM you need to worry about, just run you exe
file) I think that that kind of a concept is avoided in Java mainly due
to the complexity of deployment. if you add something like MS's
clickOnce or Sun's Java Web Start to the mix, you'll got yourself a
winner. it'll be better than Adobe's AIR since it's native, and the
right click works!
this could be the thing that puts D on the map, like ruby on rails did
for Ruby.

We do not need to create a full featured RMI like API for this, but rather use Tango's IO.

Yigal Chripun schrieb:
> I want the ability to have a native GUI client connect to a server that
> provides a service (Wweb browser, mail, Gmail, etc). basically all those
> "web applications" like Gmail could be replaced by this.
> I see it as a very powerful feature, especially given that in D it would
> be trivial to use (No JVM you need to worry about, just run you exe
> file) I think that that kind of a concept is avoided in Java mainly due
> to the complexity of deployment. if you add something like MS's
> clickOnce or Sun's Java Web Start to the mix, you'll got yourself a
> winner. it'll be better than Adobe's AIR since it's native, and the
> right click works!
> this could be the thing that puts D on the map, like ruby on rails did
> for Ruby.
> 
> We do not need to create a full featured RMI like API for this, but
> rather use Tango's IO.

Do i get your idea right? ...

The user gets a binary (.exe) to download, which contains e.g. a DWT application.

After starting it, this application can contact a service from a remote server. After the connection is established, the remote service can use the local DWT as GUI Frontend.

The remote service is also a D application.

OK, that sound interesting. But DWT is here only a nice showcase, not part of technologie, right?

Frank Benoit wrote:
> Yigal Chripun schrieb:
>> I want the ability to have a native GUI client connect to a server that
>> provides a service (Wweb browser, mail, Gmail, etc). basically all those
>> "web applications" like Gmail could be replaced by this.
>> I see it as a very powerful feature, especially given that in D it would
>> be trivial to use (No JVM you need to worry about, just run you exe
>> file) I think that that kind of a concept is avoided in Java mainly due
>> to the complexity of deployment. if you add something like MS's
>> clickOnce or Sun's Java Web Start to the mix, you'll got yourself a
>> winner. it'll be better than Adobe's AIR since it's native, and the
>> right click works!
>> this could be the thing that puts D on the map, like ruby on rails did
>> for Ruby.
>>
>> We do not need to create a full featured RMI like API for this, but rather use Tango's IO.
> 
> Do i get your idea right? ...
> 
> The user gets a binary (.exe) to download, which contains e.g. a DWT
> application.
> 
> After starting it, this application can contact a service from a remote server. After the connection is established, the remote service can use the local DWT as GUI Frontend.
> 
> The remote service is also a D application.
> 
> OK, that sound interesting. But DWT is here only a nice showcase, not part of technologie, right?

this is more or less the general gist of it.
a good example to explain the possible use cases is Gmail.
currently its GUI is rendered inside a browser on the client side via a
javascript library. the end goal of the concept is to enable to /easily/
replace that javascript code (generated from Java by their toolkit...)
with a native client GUI made with DWT.
you press a link on the Gmail site and presto the native client is
downloaded and deployed locally so you can now enjoy a real UI that is
not limited to HTML just like any other desktop application on your
computer.
Just like Java web start only without requiring a huge JVM and which
actually always works, just like adobe AIR only not proprietary and with
the right click working, like microsoft's ClickOnce only cross platform
and open. And it'll give you a /native/ look and feel thanks to DWT!

DWT is a major part here since it provides a very clean API, D itself provides for performance and ability to provide bindings for other languages through its linkage with C (important for interoperability).

if you want to discuss this concept further I'll be happy to discuss more fine-grained details.

--Yigal