www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.dwt - RSWT [SWT on top of RMI]

reply Yigal Chripun <yigal100 gmail.com> writes:
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?
Jun 08 2008
parent reply Frank Benoit <keinfarbton googlemail.com> writes:
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.
Jun 08 2008
parent reply Yigal Chripun <yigal100 gmail.com> writes:
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.
Jun 08 2008
parent reply Frank Benoit <keinfarbton googlemail.com> writes:
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?

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?
Jun 08 2008
parent reply Yigal Chripun <yigal100 gmail.com> writes:
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?

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.
Jun 08 2008
parent reply Frank Benoit <keinfarbton googlemail.com> writes:
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?
Jun 08 2008
parent Yigal Chripun <yigal100 gmail.com> writes:
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
Jun 08 2008