You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@thrift.apache.org by "Fredrik Hedberg (JIRA)" <ji...@apache.org> on 2008/09/16 11:01:44 UTC
[jira] Created: (THRIFT-137) Asynchronous client transports
Asynchronous client transports
------------------------------
Key: THRIFT-137
URL: https://issues.apache.org/jira/browse/THRIFT-137
Project: Thrift
Issue Type: Improvement
Components: Compiler (Java)
Reporter: Fredrik Hedberg
Priority: Minor
As previously discussed on the mailinglist, using Thrift from Google Web Toolkit (GWT) applications (AJAX) would be nice, as it does not only allow you to consume existing Thrift services from GWT applications, but also means that you now can write GWT-consumable RPC services in any language (and say host them on Google Appengine) that are practically source-code compatible with the official GWT RPC framework.
Doing this presents two challanges:
1) The GWT compiler only supports a subset of the JRE libraries (luckily, this is rather easy to work around).
2) As the A in AJAX hints, the only way of doing RPC is asynchronously, something not supported by Thrift, by using the XMLHttpRequest object in the browser.
Here's what I've done (an excerpt from the mailing-list):
--snip--
1) Created a stripped down jar of Thrift, axed most protocol, transport and server implementations, in order to get a JavaScript-translatable version of Thrift. I did not need to change any of the base Thrift classes, nor modify the compiler for GWT to translate the structs, but I might have missed something here (Mathias?).
2) Added an option for the Thrift Java compiler to generate asynchronous service interfaces and client proxies. This is manifested as:
public class Repository {
public interface Iface {
public Document get_document(String uri) throws TException;
public int get_count() throws TException;
}
public interface AsyncIface {
public void get_document(String uri, TAsyncCallback<Document>
callback) throws TException;
public void get_count(TAsyncCallback<Integer> callback) throws TException;
}
...
This is done in line with GWT's RPC framework and gives the developer the standard synchronous interface to implement on the server side (I use it with embedded Jetty in a daemon) and an asynchonous interface to use in the GWT client. AsyncCallback<T> just has a plain onSuccess(T result) method.
3) Implemented a client transport using GWT's RequestBuilder (the XmlHttpRequest abstraction) that executes the TAsyncCallback asynchronously when the response has been received.
4) Modified the JSONProtocol slightly to be fully JavaScript-translatable. This could probably be more efficiently done by using GWT's JSNI framework, but I really haven't had the time to optimize anything yet.
--snip--
This solution works really well for my problem, but it's half-assed in two ways.
1) It only allows for asynchronous client transports (as in the case of the XMLHttpRequest object) and not on the server side (with messages coming back in a non-sequential order).
2) I'm not sure how to solve the client library issues. Right now, I've moved the core classes (those required on the client (GWT) side of things) into com.facebook.thrift.gwt, while keeping everything else where they are. This allows the GWT compiler to translate com.facebook.thrift.gwt.* while using the same jar both on the client and server. This is not very elegant for people not using GWT (which I suppose is 99.99% of the audience) but short of maintaining two separate Java client libraries, I'm not sure how to solve this issue.
The attached patch is only for the compiler, and does not produce compilable client code without the modified client library. Just wanted to get some input before producing a somewhat committable patch. Comments? Ideas?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [jira] Commented: (THRIFT-137) Asynchronous client transports
Posted by Mathias Herberts <ma...@gmail.com>.
On Tue, Sep 16, 2008 at 2:26 PM, Fredrik Hedberg (JIRA) <ji...@apache.org> wrote:
>
> [ https://issues.apache.org/jira/browse/THRIFT-137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12631362#action_12631362 ]
>
> Fredrik Hedberg commented on THRIFT-137:
> ----------------------------------------
>
> Ah, now I better understand what you did ;)
>
> However, I'm not sure I understand the use-case here. Why would one want to generate GWT RPC services definitions from Thrift IDLs rather than creating them manually, when it's impossible to produce or consume these services without using the GWT RPC framework (ie. nothing but the GWT client could consume them, and nothing but a Java servlet implementing GWT's RemoteServiceServlet could produce them)?
I actually produce both versions, the *pure* Thrift one and the GWT
one. The GWT services are consumed from the frontend and the Thrift
ones on the backend, the GWT service is mainly a light gateway to the
Thrift service, simply doing some trivial checks and converting the
GWT version of a struct to its pure Thrift counterpart.
This allows me to maintain coherency and simplicity throughout the code.
Mathias.
[jira] Issue Comment Edited: (THRIFT-137) Asynchronous client
transports
Posted by "Fredrik Hedberg (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/THRIFT-137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12645802#action_12645802 ]
fhedberg edited comment on THRIFT-137 at 11/7/08 8:00 AM:
-----------------------------------------------------------------
And if anybody dare to try it, compile the Thrift Java library with 'GWT_HOME=/usr/local/... ant compile-gwt dist' and generate your client code with 'thrift --gen java:beans,async example.thrift'.
{{ final Repository.AsyncIface client = (Repository.AsyncIface) GWT
.create(Repository.AsyncIface.class);
button.addClickListener(new ClickListener() {
public void onClick(Widget sender) {
try {
client.get_document("http://www.host.com/document.html",
new TAsyncCallback<Document>() {
public void onFailure(Throwable throwable) {
Window.alert("Boom!");
}
public void onSuccess(Document result) {
dialogLabel.setText("Success (" + result.getUri() + "): "
+ result.getContent());
dialogBox.center();
dialogBox.show();
}
});
} catch (Exception e) {
}
}
});}}
was (Author: fhedberg):
And if anybody dare to try it, compile the Thrift Java library with 'GWT_HOME=/usr/local/... ant compile-gwt dist' and generate your client code with 'thrift --gen java:beans,async example.thrift'.
final Repository.AsyncIface client = (Repository.AsyncIface) GWT
.create(Repository.AsyncIface.class);
button.addClickListener(new ClickListener() {
public void onClick(Widget sender) {
try {
client.get_document("http://www.host.com/document.html",
new TAsyncCallback<Document>() {
public void onFailure(Throwable throwable) {
Window.alert("Boom!");
}
public void onSuccess(Document result) {
dialogLabel.setText("Success (" + result.getUri() + "): "
+ result.getContent());
dialogBox.center();
dialogBox.show();
}
});
} catch (Exception e) {
}
}
});
> Asynchronous client transports
> ------------------------------
>
> Key: THRIFT-137
> URL: https://issues.apache.org/jira/browse/THRIFT-137
> Project: Thrift
> Issue Type: New Feature
> Components: Compiler (Java), Library (Java)
> Reporter: Fredrik Hedberg
> Priority: Minor
> Attachments: GWTHelper.java, thrift-compiler-gwt-path, thrift-gwt-2.diff, thrift-gwt-3.diff, thrift-gwt-4.diff, thrift-gwt.diff
>
>
> As previously discussed on the mailinglist, using Thrift from Google Web Toolkit (GWT) applications (AJAX) would be nice, as it does not only allow you to consume existing Thrift services from GWT applications, but also means that you now can write GWT-consumable RPC services in any language (and say host them on Google Appengine) that are practically source-code compatible with the official GWT RPC framework.
> Doing this presents two challanges:
> 1) The GWT compiler only supports a subset of the JRE libraries (luckily, this is rather easy to work around).
> 2) As the A in AJAX hints, the only way of doing RPC is asynchronously, something not supported by Thrift, by using the XMLHttpRequest object in the browser.
> Here's what I've done (an excerpt from the mailing-list):
> --snip--
> 1) Created a stripped down jar of Thrift, axed most protocol, transport and server implementations, in order to get a JavaScript-translatable version of Thrift. I did not need to change any of the base Thrift classes, nor modify the compiler for GWT to translate the structs, but I might have missed something here (Mathias?).
> 2) Added an option for the Thrift Java compiler to generate asynchronous service interfaces and client proxies. This is manifested as:
> public class Repository {
> public interface Iface {
> public Document get_document(String uri) throws TException;
> public int get_count() throws TException;
> }
> public interface AsyncIface {
> public void get_document(String uri, TAsyncCallback<Document>
> callback) throws TException;
> public void get_count(TAsyncCallback<Integer> callback) throws TException;
> }
> ...
> This is done in line with GWT's RPC framework and gives the developer the standard synchronous interface to implement on the server side (I use it with embedded Jetty in a daemon) and an asynchonous interface to use in the GWT client. AsyncCallback<T> just has a plain onSuccess(T result) method.
> 3) Implemented a client transport using GWT's RequestBuilder (the XmlHttpRequest abstraction) that executes the TAsyncCallback asynchronously when the response has been received.
> 4) Modified the JSONProtocol slightly to be fully JavaScript-translatable. This could probably be more efficiently done by using GWT's JSNI framework, but I really haven't had the time to optimize anything yet.
> --snip--
> This solution works really well for my problem, but it's half-assed in two ways.
> 1) It only allows for asynchronous client transports (as in the case of the XMLHttpRequest object) and not on the server side (with messages coming back in a non-sequential order).
> 2) I'm not sure how to solve the client library issues. Right now, I've moved the core classes (those required on the client (GWT) side of things) into com.facebook.thrift.gwt, while keeping everything else where they are. This allows the GWT compiler to translate com.facebook.thrift.gwt.* while using the same jar both on the client and server. This is not very elegant for people not using GWT (which I suppose is 99.99% of the audience) but short of maintaining two separate Java client libraries, I'm not sure how to solve this issue.
> The attached patch is only for the compiler, and does not produce compilable client code without the modified client library. Just wanted to get some input before producing a somewhat committable patch. Comments? Ideas?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (THRIFT-137) Asynchronous client transports
Posted by "Mathias Herberts (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/THRIFT-137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mathias Herberts updated THRIFT-137:
------------------------------------
Attachment: GWTHelper.java
Helper class to convert back and forth between Thrift and GWT versions of objects.
> Asynchronous client transports
> ------------------------------
>
> Key: THRIFT-137
> URL: https://issues.apache.org/jira/browse/THRIFT-137
> Project: Thrift
> Issue Type: Improvement
> Components: Compiler (Java)
> Reporter: Fredrik Hedberg
> Priority: Minor
> Attachments: GWTHelper.java, thrift-compiler-gwt-path, thrift-gwt.diff
>
>
> As previously discussed on the mailinglist, using Thrift from Google Web Toolkit (GWT) applications (AJAX) would be nice, as it does not only allow you to consume existing Thrift services from GWT applications, but also means that you now can write GWT-consumable RPC services in any language (and say host them on Google Appengine) that are practically source-code compatible with the official GWT RPC framework.
> Doing this presents two challanges:
> 1) The GWT compiler only supports a subset of the JRE libraries (luckily, this is rather easy to work around).
> 2) As the A in AJAX hints, the only way of doing RPC is asynchronously, something not supported by Thrift, by using the XMLHttpRequest object in the browser.
> Here's what I've done (an excerpt from the mailing-list):
> --snip--
> 1) Created a stripped down jar of Thrift, axed most protocol, transport and server implementations, in order to get a JavaScript-translatable version of Thrift. I did not need to change any of the base Thrift classes, nor modify the compiler for GWT to translate the structs, but I might have missed something here (Mathias?).
> 2) Added an option for the Thrift Java compiler to generate asynchronous service interfaces and client proxies. This is manifested as:
> public class Repository {
> public interface Iface {
> public Document get_document(String uri) throws TException;
> public int get_count() throws TException;
> }
> public interface AsyncIface {
> public void get_document(String uri, TAsyncCallback<Document>
> callback) throws TException;
> public void get_count(TAsyncCallback<Integer> callback) throws TException;
> }
> ...
> This is done in line with GWT's RPC framework and gives the developer the standard synchronous interface to implement on the server side (I use it with embedded Jetty in a daemon) and an asynchonous interface to use in the GWT client. AsyncCallback<T> just has a plain onSuccess(T result) method.
> 3) Implemented a client transport using GWT's RequestBuilder (the XmlHttpRequest abstraction) that executes the TAsyncCallback asynchronously when the response has been received.
> 4) Modified the JSONProtocol slightly to be fully JavaScript-translatable. This could probably be more efficiently done by using GWT's JSNI framework, but I really haven't had the time to optimize anything yet.
> --snip--
> This solution works really well for my problem, but it's half-assed in two ways.
> 1) It only allows for asynchronous client transports (as in the case of the XMLHttpRequest object) and not on the server side (with messages coming back in a non-sequential order).
> 2) I'm not sure how to solve the client library issues. Right now, I've moved the core classes (those required on the client (GWT) side of things) into com.facebook.thrift.gwt, while keeping everything else where they are. This allows the GWT compiler to translate com.facebook.thrift.gwt.* while using the same jar both on the client and server. This is not very elegant for people not using GWT (which I suppose is 99.99% of the audience) but short of maintaining two separate Java client libraries, I'm not sure how to solve this issue.
> The attached patch is only for the compiler, and does not produce compilable client code without the modified client library. Just wanted to get some input before producing a somewhat committable patch. Comments? Ideas?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (THRIFT-137) Asynchronous client
transports
Posted by "Fredrik Hedberg (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/THRIFT-137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12637516#action_12637516 ]
fhedberg edited comment on THRIFT-137 at 10/7/08 8:17 AM:
-----------------------------------------------------------------
New version of the modifications; now including the client library side of it that wasn't submitted the last time. Compile the Thrift Java library with 'ant compile-gwt dist' to enable the GWT changes.
This should now provide fully working Thrift/GWT integration. What remains to be done is rewriting the TGWTJSONProtocol, which is currently a butchered version of the standard TJSONProtocol.
was (Author: fhedberg):
New version of the modifications; now including the client library side of it that wasn't submitted the last time. Compile the Thrift Java library with 'ant compile-gwt dist' to enable the GWT changes.
This should now provide fully working Thrift/GWT integration. What remains to be done is rewriting the TGWTJSONProtocol, which is basically a butchered version of the standard TJSONProtocol.
> Asynchronous client transports
> ------------------------------
>
> Key: THRIFT-137
> URL: https://issues.apache.org/jira/browse/THRIFT-137
> Project: Thrift
> Issue Type: New Feature
> Components: Compiler (Java), Library (Java)
> Reporter: Fredrik Hedberg
> Priority: Minor
> Attachments: GWTHelper.java, thrift-compiler-gwt-path, thrift-gwt-2.diff, thrift-gwt-3.diff, thrift-gwt.diff
>
>
> As previously discussed on the mailinglist, using Thrift from Google Web Toolkit (GWT) applications (AJAX) would be nice, as it does not only allow you to consume existing Thrift services from GWT applications, but also means that you now can write GWT-consumable RPC services in any language (and say host them on Google Appengine) that are practically source-code compatible with the official GWT RPC framework.
> Doing this presents two challanges:
> 1) The GWT compiler only supports a subset of the JRE libraries (luckily, this is rather easy to work around).
> 2) As the A in AJAX hints, the only way of doing RPC is asynchronously, something not supported by Thrift, by using the XMLHttpRequest object in the browser.
> Here's what I've done (an excerpt from the mailing-list):
> --snip--
> 1) Created a stripped down jar of Thrift, axed most protocol, transport and server implementations, in order to get a JavaScript-translatable version of Thrift. I did not need to change any of the base Thrift classes, nor modify the compiler for GWT to translate the structs, but I might have missed something here (Mathias?).
> 2) Added an option for the Thrift Java compiler to generate asynchronous service interfaces and client proxies. This is manifested as:
> public class Repository {
> public interface Iface {
> public Document get_document(String uri) throws TException;
> public int get_count() throws TException;
> }
> public interface AsyncIface {
> public void get_document(String uri, TAsyncCallback<Document>
> callback) throws TException;
> public void get_count(TAsyncCallback<Integer> callback) throws TException;
> }
> ...
> This is done in line with GWT's RPC framework and gives the developer the standard synchronous interface to implement on the server side (I use it with embedded Jetty in a daemon) and an asynchonous interface to use in the GWT client. AsyncCallback<T> just has a plain onSuccess(T result) method.
> 3) Implemented a client transport using GWT's RequestBuilder (the XmlHttpRequest abstraction) that executes the TAsyncCallback asynchronously when the response has been received.
> 4) Modified the JSONProtocol slightly to be fully JavaScript-translatable. This could probably be more efficiently done by using GWT's JSNI framework, but I really haven't had the time to optimize anything yet.
> --snip--
> This solution works really well for my problem, but it's half-assed in two ways.
> 1) It only allows for asynchronous client transports (as in the case of the XMLHttpRequest object) and not on the server side (with messages coming back in a non-sequential order).
> 2) I'm not sure how to solve the client library issues. Right now, I've moved the core classes (those required on the client (GWT) side of things) into com.facebook.thrift.gwt, while keeping everything else where they are. This allows the GWT compiler to translate com.facebook.thrift.gwt.* while using the same jar both on the client and server. This is not very elegant for people not using GWT (which I suppose is 99.99% of the audience) but short of maintaining two separate Java client libraries, I'm not sure how to solve this issue.
> The attached patch is only for the compiler, and does not produce compilable client code without the modified client library. Just wanted to get some input before producing a somewhat committable patch. Comments? Ideas?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (THRIFT-137) Asynchronous client transports
Posted by "Fredrik Hedberg (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/THRIFT-137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12631362#action_12631362 ]
Fredrik Hedberg commented on THRIFT-137:
----------------------------------------
Ah, now I better understand what you did ;)
However, I'm not sure I understand the use-case here. Why would one want to generate GWT RPC services definitions from Thrift IDLs rather than creating them manually, when it's impossible to produce or consume these services without using the GWT RPC framework (ie. nothing but the GWT client could consume them, and nothing but a Java servlet implementing GWT's RemoteServiceServlet could produce them)?
> Asynchronous client transports
> ------------------------------
>
> Key: THRIFT-137
> URL: https://issues.apache.org/jira/browse/THRIFT-137
> Project: Thrift
> Issue Type: Improvement
> Components: Compiler (Java)
> Reporter: Fredrik Hedberg
> Priority: Minor
> Attachments: GWTHelper.java, thrift-compiler-gwt-path, thrift-gwt.diff
>
>
> As previously discussed on the mailinglist, using Thrift from Google Web Toolkit (GWT) applications (AJAX) would be nice, as it does not only allow you to consume existing Thrift services from GWT applications, but also means that you now can write GWT-consumable RPC services in any language (and say host them on Google Appengine) that are practically source-code compatible with the official GWT RPC framework.
> Doing this presents two challanges:
> 1) The GWT compiler only supports a subset of the JRE libraries (luckily, this is rather easy to work around).
> 2) As the A in AJAX hints, the only way of doing RPC is asynchronously, something not supported by Thrift, by using the XMLHttpRequest object in the browser.
> Here's what I've done (an excerpt from the mailing-list):
> --snip--
> 1) Created a stripped down jar of Thrift, axed most protocol, transport and server implementations, in order to get a JavaScript-translatable version of Thrift. I did not need to change any of the base Thrift classes, nor modify the compiler for GWT to translate the structs, but I might have missed something here (Mathias?).
> 2) Added an option for the Thrift Java compiler to generate asynchronous service interfaces and client proxies. This is manifested as:
> public class Repository {
> public interface Iface {
> public Document get_document(String uri) throws TException;
> public int get_count() throws TException;
> }
> public interface AsyncIface {
> public void get_document(String uri, TAsyncCallback<Document>
> callback) throws TException;
> public void get_count(TAsyncCallback<Integer> callback) throws TException;
> }
> ...
> This is done in line with GWT's RPC framework and gives the developer the standard synchronous interface to implement on the server side (I use it with embedded Jetty in a daemon) and an asynchonous interface to use in the GWT client. AsyncCallback<T> just has a plain onSuccess(T result) method.
> 3) Implemented a client transport using GWT's RequestBuilder (the XmlHttpRequest abstraction) that executes the TAsyncCallback asynchronously when the response has been received.
> 4) Modified the JSONProtocol slightly to be fully JavaScript-translatable. This could probably be more efficiently done by using GWT's JSNI framework, but I really haven't had the time to optimize anything yet.
> --snip--
> This solution works really well for my problem, but it's half-assed in two ways.
> 1) It only allows for asynchronous client transports (as in the case of the XMLHttpRequest object) and not on the server side (with messages coming back in a non-sequential order).
> 2) I'm not sure how to solve the client library issues. Right now, I've moved the core classes (those required on the client (GWT) side of things) into com.facebook.thrift.gwt, while keeping everything else where they are. This allows the GWT compiler to translate com.facebook.thrift.gwt.* while using the same jar both on the client and server. This is not very elegant for people not using GWT (which I suppose is 99.99% of the audience) but short of maintaining two separate Java client libraries, I'm not sure how to solve this issue.
> The attached patch is only for the compiler, and does not produce compilable client code without the modified client library. Just wanted to get some input before producing a somewhat committable patch. Comments? Ideas?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (THRIFT-137) Asynchronous client transports
Posted by "Fredrik Hedberg (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/THRIFT-137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Fredrik Hedberg updated THRIFT-137:
-----------------------------------
Attachment: thrift-gwt-3.diff
New version of the modifications; now including the client library side of it that wasn't submitted the last time. Compile the Thrift Java library with 'ant compile-gwt dist' to enable the GWT changes.
This should now provide fully working Thrift/GWT integration. What remains to be done is rewriting the TGWTJSONProtocol, which is basically a butchered version of the standard TJSONProtocol.
> Asynchronous client transports
> ------------------------------
>
> Key: THRIFT-137
> URL: https://issues.apache.org/jira/browse/THRIFT-137
> Project: Thrift
> Issue Type: Improvement
> Components: Compiler (Java)
> Reporter: Fredrik Hedberg
> Priority: Minor
> Attachments: GWTHelper.java, thrift-compiler-gwt-path, thrift-gwt-2.diff, thrift-gwt-3.diff, thrift-gwt.diff
>
>
> As previously discussed on the mailinglist, using Thrift from Google Web Toolkit (GWT) applications (AJAX) would be nice, as it does not only allow you to consume existing Thrift services from GWT applications, but also means that you now can write GWT-consumable RPC services in any language (and say host them on Google Appengine) that are practically source-code compatible with the official GWT RPC framework.
> Doing this presents two challanges:
> 1) The GWT compiler only supports a subset of the JRE libraries (luckily, this is rather easy to work around).
> 2) As the A in AJAX hints, the only way of doing RPC is asynchronously, something not supported by Thrift, by using the XMLHttpRequest object in the browser.
> Here's what I've done (an excerpt from the mailing-list):
> --snip--
> 1) Created a stripped down jar of Thrift, axed most protocol, transport and server implementations, in order to get a JavaScript-translatable version of Thrift. I did not need to change any of the base Thrift classes, nor modify the compiler for GWT to translate the structs, but I might have missed something here (Mathias?).
> 2) Added an option for the Thrift Java compiler to generate asynchronous service interfaces and client proxies. This is manifested as:
> public class Repository {
> public interface Iface {
> public Document get_document(String uri) throws TException;
> public int get_count() throws TException;
> }
> public interface AsyncIface {
> public void get_document(String uri, TAsyncCallback<Document>
> callback) throws TException;
> public void get_count(TAsyncCallback<Integer> callback) throws TException;
> }
> ...
> This is done in line with GWT's RPC framework and gives the developer the standard synchronous interface to implement on the server side (I use it with embedded Jetty in a daemon) and an asynchonous interface to use in the GWT client. AsyncCallback<T> just has a plain onSuccess(T result) method.
> 3) Implemented a client transport using GWT's RequestBuilder (the XmlHttpRequest abstraction) that executes the TAsyncCallback asynchronously when the response has been received.
> 4) Modified the JSONProtocol slightly to be fully JavaScript-translatable. This could probably be more efficiently done by using GWT's JSNI framework, but I really haven't had the time to optimize anything yet.
> --snip--
> This solution works really well for my problem, but it's half-assed in two ways.
> 1) It only allows for asynchronous client transports (as in the case of the XMLHttpRequest object) and not on the server side (with messages coming back in a non-sequential order).
> 2) I'm not sure how to solve the client library issues. Right now, I've moved the core classes (those required on the client (GWT) side of things) into com.facebook.thrift.gwt, while keeping everything else where they are. This allows the GWT compiler to translate com.facebook.thrift.gwt.* while using the same jar both on the client and server. This is not very elegant for people not using GWT (which I suppose is 99.99% of the audience) but short of maintaining two separate Java client libraries, I'm not sure how to solve this issue.
> The attached patch is only for the compiler, and does not produce compilable client code without the modified client library. Just wanted to get some input before producing a somewhat committable patch. Comments? Ideas?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (THRIFT-137) Asynchronous client transports
Posted by "Mathias Herberts (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/THRIFT-137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mathias Herberts updated THRIFT-137:
------------------------------------
Attachment: thrift-compiler-gwt-path
Patch to the Java generator to accept a new 'gwt' option that will generate GWT compatible versions of classes.
> Asynchronous client transports
> ------------------------------
>
> Key: THRIFT-137
> URL: https://issues.apache.org/jira/browse/THRIFT-137
> Project: Thrift
> Issue Type: Improvement
> Components: Compiler (Java)
> Reporter: Fredrik Hedberg
> Priority: Minor
> Attachments: thrift-compiler-gwt-path, thrift-gwt.diff
>
>
> As previously discussed on the mailinglist, using Thrift from Google Web Toolkit (GWT) applications (AJAX) would be nice, as it does not only allow you to consume existing Thrift services from GWT applications, but also means that you now can write GWT-consumable RPC services in any language (and say host them on Google Appengine) that are practically source-code compatible with the official GWT RPC framework.
> Doing this presents two challanges:
> 1) The GWT compiler only supports a subset of the JRE libraries (luckily, this is rather easy to work around).
> 2) As the A in AJAX hints, the only way of doing RPC is asynchronously, something not supported by Thrift, by using the XMLHttpRequest object in the browser.
> Here's what I've done (an excerpt from the mailing-list):
> --snip--
> 1) Created a stripped down jar of Thrift, axed most protocol, transport and server implementations, in order to get a JavaScript-translatable version of Thrift. I did not need to change any of the base Thrift classes, nor modify the compiler for GWT to translate the structs, but I might have missed something here (Mathias?).
> 2) Added an option for the Thrift Java compiler to generate asynchronous service interfaces and client proxies. This is manifested as:
> public class Repository {
> public interface Iface {
> public Document get_document(String uri) throws TException;
> public int get_count() throws TException;
> }
> public interface AsyncIface {
> public void get_document(String uri, TAsyncCallback<Document>
> callback) throws TException;
> public void get_count(TAsyncCallback<Integer> callback) throws TException;
> }
> ...
> This is done in line with GWT's RPC framework and gives the developer the standard synchronous interface to implement on the server side (I use it with embedded Jetty in a daemon) and an asynchonous interface to use in the GWT client. AsyncCallback<T> just has a plain onSuccess(T result) method.
> 3) Implemented a client transport using GWT's RequestBuilder (the XmlHttpRequest abstraction) that executes the TAsyncCallback asynchronously when the response has been received.
> 4) Modified the JSONProtocol slightly to be fully JavaScript-translatable. This could probably be more efficiently done by using GWT's JSNI framework, but I really haven't had the time to optimize anything yet.
> --snip--
> This solution works really well for my problem, but it's half-assed in two ways.
> 1) It only allows for asynchronous client transports (as in the case of the XMLHttpRequest object) and not on the server side (with messages coming back in a non-sequential order).
> 2) I'm not sure how to solve the client library issues. Right now, I've moved the core classes (those required on the client (GWT) side of things) into com.facebook.thrift.gwt, while keeping everything else where they are. This allows the GWT compiler to translate com.facebook.thrift.gwt.* while using the same jar both on the client and server. This is not very elegant for people not using GWT (which I suppose is 99.99% of the audience) but short of maintaining two separate Java client libraries, I'm not sure how to solve this issue.
> The attached patch is only for the compiler, and does not produce compilable client code without the modified client library. Just wanted to get some input before producing a somewhat committable patch. Comments? Ideas?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (THRIFT-137) Asynchronous client
transports
Posted by "Fredrik Hedberg (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/THRIFT-137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12645802#action_12645802 ]
fhedberg edited comment on THRIFT-137 at 11/7/08 8:02 AM:
-----------------------------------------------------------------
And if anybody dare to try it, compile the Thrift Java library with 'GWT_HOME=/usr/local/... ant compile-gwt dist' and generate your client code with 'thrift --gen java:beans,async example.thrift'.
final Repository.AsyncIface client = (Repository.AsyncIface) GWT
.create(Repository.AsyncIface.class);
button.addClickListener(new ClickListener() {
public void onClick(Widget sender) {
try {
client.get_document("http://www.host.com/document.html",
new TAsyncCallback<Document>() {
public void onFailure(Throwable throwable) {
Window.alert("Boom!");
}
public void onSuccess(Document result) {
dialogLabel.setText("Success (" + result.getUri() + "): "
+ result.getContent());
}
});
} catch (Exception e) {
}
}
});
was (Author: fhedberg):
And if anybody dare to try it, compile the Thrift Java library with 'GWT_HOME=/usr/local/... ant compile-gwt dist' and generate your client code with 'thrift --gen java:beans,async example.thrift'.
{{ final Repository.AsyncIface client = (Repository.AsyncIface) GWT
.create(Repository.AsyncIface.class);
button.addClickListener(new ClickListener() {
public void onClick(Widget sender) {
try {
client.get_document("http://www.host.com/document.html",
new TAsyncCallback<Document>() {
public void onFailure(Throwable throwable) {
Window.alert("Boom!");
}
public void onSuccess(Document result) {
dialogLabel.setText("Success (" + result.getUri() + "): "
+ result.getContent());
dialogBox.center();
dialogBox.show();
}
});
} catch (Exception e) {
}
}
});}}
> Asynchronous client transports
> ------------------------------
>
> Key: THRIFT-137
> URL: https://issues.apache.org/jira/browse/THRIFT-137
> Project: Thrift
> Issue Type: New Feature
> Components: Compiler (Java), Library (Java)
> Reporter: Fredrik Hedberg
> Priority: Minor
> Attachments: GWTHelper.java, thrift-compiler-gwt-path, thrift-gwt-2.diff, thrift-gwt-3.diff, thrift-gwt-4.diff, thrift-gwt.diff
>
>
> As previously discussed on the mailinglist, using Thrift from Google Web Toolkit (GWT) applications (AJAX) would be nice, as it does not only allow you to consume existing Thrift services from GWT applications, but also means that you now can write GWT-consumable RPC services in any language (and say host them on Google Appengine) that are practically source-code compatible with the official GWT RPC framework.
> Doing this presents two challanges:
> 1) The GWT compiler only supports a subset of the JRE libraries (luckily, this is rather easy to work around).
> 2) As the A in AJAX hints, the only way of doing RPC is asynchronously, something not supported by Thrift, by using the XMLHttpRequest object in the browser.
> Here's what I've done (an excerpt from the mailing-list):
> --snip--
> 1) Created a stripped down jar of Thrift, axed most protocol, transport and server implementations, in order to get a JavaScript-translatable version of Thrift. I did not need to change any of the base Thrift classes, nor modify the compiler for GWT to translate the structs, but I might have missed something here (Mathias?).
> 2) Added an option for the Thrift Java compiler to generate asynchronous service interfaces and client proxies. This is manifested as:
> public class Repository {
> public interface Iface {
> public Document get_document(String uri) throws TException;
> public int get_count() throws TException;
> }
> public interface AsyncIface {
> public void get_document(String uri, TAsyncCallback<Document>
> callback) throws TException;
> public void get_count(TAsyncCallback<Integer> callback) throws TException;
> }
> ...
> This is done in line with GWT's RPC framework and gives the developer the standard synchronous interface to implement on the server side (I use it with embedded Jetty in a daemon) and an asynchonous interface to use in the GWT client. AsyncCallback<T> just has a plain onSuccess(T result) method.
> 3) Implemented a client transport using GWT's RequestBuilder (the XmlHttpRequest abstraction) that executes the TAsyncCallback asynchronously when the response has been received.
> 4) Modified the JSONProtocol slightly to be fully JavaScript-translatable. This could probably be more efficiently done by using GWT's JSNI framework, but I really haven't had the time to optimize anything yet.
> --snip--
> This solution works really well for my problem, but it's half-assed in two ways.
> 1) It only allows for asynchronous client transports (as in the case of the XMLHttpRequest object) and not on the server side (with messages coming back in a non-sequential order).
> 2) I'm not sure how to solve the client library issues. Right now, I've moved the core classes (those required on the client (GWT) side of things) into com.facebook.thrift.gwt, while keeping everything else where they are. This allows the GWT compiler to translate com.facebook.thrift.gwt.* while using the same jar both on the client and server. This is not very elegant for people not using GWT (which I suppose is 99.99% of the audience) but short of maintaining two separate Java client libraries, I'm not sure how to solve this issue.
> The attached patch is only for the compiler, and does not produce compilable client code without the modified client library. Just wanted to get some input before producing a somewhat committable patch. Comments? Ideas?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (THRIFT-137) Asynchronous client transports
Posted by "Fredrik Hedberg (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/THRIFT-137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Fredrik Hedberg updated THRIFT-137:
-----------------------------------
Attachment: thrift-gwt-4.diff
Fourth iteration of the GWT patch.
Now included is a TGWTProtocol JSON implementation that uses the native GWT JSON parser (compatible with the standard JSONProtocol implementation), and a TGWTProxyGenerator that provides deferred binding support for Thrift cilents. This means that it's now as easy to use Thrift from GWT as using the standard GWT RPC framework.
Also, I made some build changes since the last patch which means that a single JAR can be used for both server and client code, but also that I did not have to modify or move any of the existing classes (almost).
I suppose the patch is more or less committable, as it is now feature complete, but I'm sure there's a bunch of bugs in the GWT part of it and could definitely use a pair of extra eyes.....
> Asynchronous client transports
> ------------------------------
>
> Key: THRIFT-137
> URL: https://issues.apache.org/jira/browse/THRIFT-137
> Project: Thrift
> Issue Type: New Feature
> Components: Compiler (Java), Library (Java)
> Reporter: Fredrik Hedberg
> Priority: Minor
> Attachments: GWTHelper.java, thrift-compiler-gwt-path, thrift-gwt-2.diff, thrift-gwt-3.diff, thrift-gwt-4.diff, thrift-gwt.diff
>
>
> As previously discussed on the mailinglist, using Thrift from Google Web Toolkit (GWT) applications (AJAX) would be nice, as it does not only allow you to consume existing Thrift services from GWT applications, but also means that you now can write GWT-consumable RPC services in any language (and say host them on Google Appengine) that are practically source-code compatible with the official GWT RPC framework.
> Doing this presents two challanges:
> 1) The GWT compiler only supports a subset of the JRE libraries (luckily, this is rather easy to work around).
> 2) As the A in AJAX hints, the only way of doing RPC is asynchronously, something not supported by Thrift, by using the XMLHttpRequest object in the browser.
> Here's what I've done (an excerpt from the mailing-list):
> --snip--
> 1) Created a stripped down jar of Thrift, axed most protocol, transport and server implementations, in order to get a JavaScript-translatable version of Thrift. I did not need to change any of the base Thrift classes, nor modify the compiler for GWT to translate the structs, but I might have missed something here (Mathias?).
> 2) Added an option for the Thrift Java compiler to generate asynchronous service interfaces and client proxies. This is manifested as:
> public class Repository {
> public interface Iface {
> public Document get_document(String uri) throws TException;
> public int get_count() throws TException;
> }
> public interface AsyncIface {
> public void get_document(String uri, TAsyncCallback<Document>
> callback) throws TException;
> public void get_count(TAsyncCallback<Integer> callback) throws TException;
> }
> ...
> This is done in line with GWT's RPC framework and gives the developer the standard synchronous interface to implement on the server side (I use it with embedded Jetty in a daemon) and an asynchonous interface to use in the GWT client. AsyncCallback<T> just has a plain onSuccess(T result) method.
> 3) Implemented a client transport using GWT's RequestBuilder (the XmlHttpRequest abstraction) that executes the TAsyncCallback asynchronously when the response has been received.
> 4) Modified the JSONProtocol slightly to be fully JavaScript-translatable. This could probably be more efficiently done by using GWT's JSNI framework, but I really haven't had the time to optimize anything yet.
> --snip--
> This solution works really well for my problem, but it's half-assed in two ways.
> 1) It only allows for asynchronous client transports (as in the case of the XMLHttpRequest object) and not on the server side (with messages coming back in a non-sequential order).
> 2) I'm not sure how to solve the client library issues. Right now, I've moved the core classes (those required on the client (GWT) side of things) into com.facebook.thrift.gwt, while keeping everything else where they are. This allows the GWT compiler to translate com.facebook.thrift.gwt.* while using the same jar both on the client and server. This is not very elegant for people not using GWT (which I suppose is 99.99% of the audience) but short of maintaining two separate Java client libraries, I'm not sure how to solve this issue.
> The attached patch is only for the compiler, and does not produce compilable client code without the modified client library. Just wanted to get some input before producing a somewhat committable patch. Comments? Ideas?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (THRIFT-137) Asynchronous client transports
Posted by "Fredrik Hedberg (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/THRIFT-137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Fredrik Hedberg updated THRIFT-137:
-----------------------------------
Component/s: Library (Java)
Issue Type: New Feature (was: Improvement)
> Asynchronous client transports
> ------------------------------
>
> Key: THRIFT-137
> URL: https://issues.apache.org/jira/browse/THRIFT-137
> Project: Thrift
> Issue Type: New Feature
> Components: Compiler (Java), Library (Java)
> Reporter: Fredrik Hedberg
> Priority: Minor
> Attachments: GWTHelper.java, thrift-compiler-gwt-path, thrift-gwt-2.diff, thrift-gwt-3.diff, thrift-gwt.diff
>
>
> As previously discussed on the mailinglist, using Thrift from Google Web Toolkit (GWT) applications (AJAX) would be nice, as it does not only allow you to consume existing Thrift services from GWT applications, but also means that you now can write GWT-consumable RPC services in any language (and say host them on Google Appengine) that are practically source-code compatible with the official GWT RPC framework.
> Doing this presents two challanges:
> 1) The GWT compiler only supports a subset of the JRE libraries (luckily, this is rather easy to work around).
> 2) As the A in AJAX hints, the only way of doing RPC is asynchronously, something not supported by Thrift, by using the XMLHttpRequest object in the browser.
> Here's what I've done (an excerpt from the mailing-list):
> --snip--
> 1) Created a stripped down jar of Thrift, axed most protocol, transport and server implementations, in order to get a JavaScript-translatable version of Thrift. I did not need to change any of the base Thrift classes, nor modify the compiler for GWT to translate the structs, but I might have missed something here (Mathias?).
> 2) Added an option for the Thrift Java compiler to generate asynchronous service interfaces and client proxies. This is manifested as:
> public class Repository {
> public interface Iface {
> public Document get_document(String uri) throws TException;
> public int get_count() throws TException;
> }
> public interface AsyncIface {
> public void get_document(String uri, TAsyncCallback<Document>
> callback) throws TException;
> public void get_count(TAsyncCallback<Integer> callback) throws TException;
> }
> ...
> This is done in line with GWT's RPC framework and gives the developer the standard synchronous interface to implement on the server side (I use it with embedded Jetty in a daemon) and an asynchonous interface to use in the GWT client. AsyncCallback<T> just has a plain onSuccess(T result) method.
> 3) Implemented a client transport using GWT's RequestBuilder (the XmlHttpRequest abstraction) that executes the TAsyncCallback asynchronously when the response has been received.
> 4) Modified the JSONProtocol slightly to be fully JavaScript-translatable. This could probably be more efficiently done by using GWT's JSNI framework, but I really haven't had the time to optimize anything yet.
> --snip--
> This solution works really well for my problem, but it's half-assed in two ways.
> 1) It only allows for asynchronous client transports (as in the case of the XMLHttpRequest object) and not on the server side (with messages coming back in a non-sequential order).
> 2) I'm not sure how to solve the client library issues. Right now, I've moved the core classes (those required on the client (GWT) side of things) into com.facebook.thrift.gwt, while keeping everything else where they are. This allows the GWT compiler to translate com.facebook.thrift.gwt.* while using the same jar both on the client and server. This is not very elegant for people not using GWT (which I suppose is 99.99% of the audience) but short of maintaining two separate Java client libraries, I'm not sure how to solve this issue.
> The attached patch is only for the compiler, and does not produce compilable client code without the modified client library. Just wanted to get some input before producing a somewhat committable patch. Comments? Ideas?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (THRIFT-137) Asynchronous client transports
Posted by "Fredrik Hedberg (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/THRIFT-137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Fredrik Hedberg updated THRIFT-137:
-----------------------------------
Attachment: thrift-gwt-2.diff
New version of the compiler modifications. Now generates the asynchronous client in addition to the standard one.
> Asynchronous client transports
> ------------------------------
>
> Key: THRIFT-137
> URL: https://issues.apache.org/jira/browse/THRIFT-137
> Project: Thrift
> Issue Type: Improvement
> Components: Compiler (Java)
> Reporter: Fredrik Hedberg
> Priority: Minor
> Attachments: GWTHelper.java, thrift-compiler-gwt-path, thrift-gwt-2.diff, thrift-gwt.diff
>
>
> As previously discussed on the mailinglist, using Thrift from Google Web Toolkit (GWT) applications (AJAX) would be nice, as it does not only allow you to consume existing Thrift services from GWT applications, but also means that you now can write GWT-consumable RPC services in any language (and say host them on Google Appengine) that are practically source-code compatible with the official GWT RPC framework.
> Doing this presents two challanges:
> 1) The GWT compiler only supports a subset of the JRE libraries (luckily, this is rather easy to work around).
> 2) As the A in AJAX hints, the only way of doing RPC is asynchronously, something not supported by Thrift, by using the XMLHttpRequest object in the browser.
> Here's what I've done (an excerpt from the mailing-list):
> --snip--
> 1) Created a stripped down jar of Thrift, axed most protocol, transport and server implementations, in order to get a JavaScript-translatable version of Thrift. I did not need to change any of the base Thrift classes, nor modify the compiler for GWT to translate the structs, but I might have missed something here (Mathias?).
> 2) Added an option for the Thrift Java compiler to generate asynchronous service interfaces and client proxies. This is manifested as:
> public class Repository {
> public interface Iface {
> public Document get_document(String uri) throws TException;
> public int get_count() throws TException;
> }
> public interface AsyncIface {
> public void get_document(String uri, TAsyncCallback<Document>
> callback) throws TException;
> public void get_count(TAsyncCallback<Integer> callback) throws TException;
> }
> ...
> This is done in line with GWT's RPC framework and gives the developer the standard synchronous interface to implement on the server side (I use it with embedded Jetty in a daemon) and an asynchonous interface to use in the GWT client. AsyncCallback<T> just has a plain onSuccess(T result) method.
> 3) Implemented a client transport using GWT's RequestBuilder (the XmlHttpRequest abstraction) that executes the TAsyncCallback asynchronously when the response has been received.
> 4) Modified the JSONProtocol slightly to be fully JavaScript-translatable. This could probably be more efficiently done by using GWT's JSNI framework, but I really haven't had the time to optimize anything yet.
> --snip--
> This solution works really well for my problem, but it's half-assed in two ways.
> 1) It only allows for asynchronous client transports (as in the case of the XMLHttpRequest object) and not on the server side (with messages coming back in a non-sequential order).
> 2) I'm not sure how to solve the client library issues. Right now, I've moved the core classes (those required on the client (GWT) side of things) into com.facebook.thrift.gwt, while keeping everything else where they are. This allows the GWT compiler to translate com.facebook.thrift.gwt.* while using the same jar both on the client and server. This is not very elegant for people not using GWT (which I suppose is 99.99% of the audience) but short of maintaining two separate Java client libraries, I'm not sure how to solve this issue.
> The attached patch is only for the compiler, and does not produce compilable client code without the modified client library. Just wanted to get some input before producing a somewhat committable patch. Comments? Ideas?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (THRIFT-137) Asynchronous client transports
Posted by "Mathias Herberts (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/THRIFT-137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12631311#action_12631311 ]
Mathias Herberts commented on THRIFT-137:
-----------------------------------------
As previously discussed on the mailing list I have also worked to make integrating Thrift structs and services with GWT easier.
Here is the path I followed.
I patched the Thrift compiler to accept an additional options for Java code generation, namely 'gwt'.
When this option is specified, the Java generator generates classes for structs in a 'gwt' subpackage of the specified namespace. Those classes are slightly modified versions of the normally generated classes. The modifications are simply the removal of the TBase inheritance, the removal of any hashcode method (as StringBuilder is not supported by GWT) and the inclusion of the isset field as non final and as part of the constructor.
A helper class has been written which using reflection converts from a Thrift TBase to its GWT counterpart.
For services, a mirror class of the Thrift one is created in the 'gwt; subpackage, this class has two inner interfaces, one for the regular service, the other one for the Async version.
I'll add my patch to this issue so anyone interested can have a look.
> Asynchronous client transports
> ------------------------------
>
> Key: THRIFT-137
> URL: https://issues.apache.org/jira/browse/THRIFT-137
> Project: Thrift
> Issue Type: Improvement
> Components: Compiler (Java)
> Reporter: Fredrik Hedberg
> Priority: Minor
> Attachments: thrift-gwt.diff
>
>
> As previously discussed on the mailinglist, using Thrift from Google Web Toolkit (GWT) applications (AJAX) would be nice, as it does not only allow you to consume existing Thrift services from GWT applications, but also means that you now can write GWT-consumable RPC services in any language (and say host them on Google Appengine) that are practically source-code compatible with the official GWT RPC framework.
> Doing this presents two challanges:
> 1) The GWT compiler only supports a subset of the JRE libraries (luckily, this is rather easy to work around).
> 2) As the A in AJAX hints, the only way of doing RPC is asynchronously, something not supported by Thrift, by using the XMLHttpRequest object in the browser.
> Here's what I've done (an excerpt from the mailing-list):
> --snip--
> 1) Created a stripped down jar of Thrift, axed most protocol, transport and server implementations, in order to get a JavaScript-translatable version of Thrift. I did not need to change any of the base Thrift classes, nor modify the compiler for GWT to translate the structs, but I might have missed something here (Mathias?).
> 2) Added an option for the Thrift Java compiler to generate asynchronous service interfaces and client proxies. This is manifested as:
> public class Repository {
> public interface Iface {
> public Document get_document(String uri) throws TException;
> public int get_count() throws TException;
> }
> public interface AsyncIface {
> public void get_document(String uri, TAsyncCallback<Document>
> callback) throws TException;
> public void get_count(TAsyncCallback<Integer> callback) throws TException;
> }
> ...
> This is done in line with GWT's RPC framework and gives the developer the standard synchronous interface to implement on the server side (I use it with embedded Jetty in a daemon) and an asynchonous interface to use in the GWT client. AsyncCallback<T> just has a plain onSuccess(T result) method.
> 3) Implemented a client transport using GWT's RequestBuilder (the XmlHttpRequest abstraction) that executes the TAsyncCallback asynchronously when the response has been received.
> 4) Modified the JSONProtocol slightly to be fully JavaScript-translatable. This could probably be more efficiently done by using GWT's JSNI framework, but I really haven't had the time to optimize anything yet.
> --snip--
> This solution works really well for my problem, but it's half-assed in two ways.
> 1) It only allows for asynchronous client transports (as in the case of the XMLHttpRequest object) and not on the server side (with messages coming back in a non-sequential order).
> 2) I'm not sure how to solve the client library issues. Right now, I've moved the core classes (those required on the client (GWT) side of things) into com.facebook.thrift.gwt, while keeping everything else where they are. This allows the GWT compiler to translate com.facebook.thrift.gwt.* while using the same jar both on the client and server. This is not very elegant for people not using GWT (which I suppose is 99.99% of the audience) but short of maintaining two separate Java client libraries, I'm not sure how to solve this issue.
> The attached patch is only for the compiler, and does not produce compilable client code without the modified client library. Just wanted to get some input before producing a somewhat committable patch. Comments? Ideas?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (THRIFT-137) GWT support for Thrift
Posted by "Fredrik Hedberg (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/THRIFT-137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Fredrik Hedberg updated THRIFT-137:
-----------------------------------
Summary: GWT support for Thrift (was: Asynchronous client transports)
> GWT support for Thrift
> ----------------------
>
> Key: THRIFT-137
> URL: https://issues.apache.org/jira/browse/THRIFT-137
> Project: Thrift
> Issue Type: New Feature
> Components: Compiler (Java), Library (Java)
> Reporter: Fredrik Hedberg
> Priority: Minor
> Attachments: GWTHelper.java, thrift-compiler-gwt-path, thrift-gwt-2.diff, thrift-gwt-3.diff, thrift-gwt-4.diff, thrift-gwt.diff
>
>
> As previously discussed on the mailinglist, using Thrift from Google Web Toolkit (GWT) applications (AJAX) would be nice, as it does not only allow you to consume existing Thrift services from GWT applications, but also means that you now can write GWT-consumable RPC services in any language (and say host them on Google Appengine) that are practically source-code compatible with the official GWT RPC framework.
> Doing this presents two challanges:
> 1) The GWT compiler only supports a subset of the JRE libraries (luckily, this is rather easy to work around).
> 2) As the A in AJAX hints, the only way of doing RPC is asynchronously, something not supported by Thrift, by using the XMLHttpRequest object in the browser.
> Here's what I've done (an excerpt from the mailing-list):
> --snip--
> 1) Created a stripped down jar of Thrift, axed most protocol, transport and server implementations, in order to get a JavaScript-translatable version of Thrift. I did not need to change any of the base Thrift classes, nor modify the compiler for GWT to translate the structs, but I might have missed something here (Mathias?).
> 2) Added an option for the Thrift Java compiler to generate asynchronous service interfaces and client proxies. This is manifested as:
> public class Repository {
> public interface Iface {
> public Document get_document(String uri) throws TException;
> public int get_count() throws TException;
> }
> public interface AsyncIface {
> public void get_document(String uri, TAsyncCallback<Document>
> callback) throws TException;
> public void get_count(TAsyncCallback<Integer> callback) throws TException;
> }
> ...
> This is done in line with GWT's RPC framework and gives the developer the standard synchronous interface to implement on the server side (I use it with embedded Jetty in a daemon) and an asynchonous interface to use in the GWT client. AsyncCallback<T> just has a plain onSuccess(T result) method.
> 3) Implemented a client transport using GWT's RequestBuilder (the XmlHttpRequest abstraction) that executes the TAsyncCallback asynchronously when the response has been received.
> 4) Modified the JSONProtocol slightly to be fully JavaScript-translatable. This could probably be more efficiently done by using GWT's JSNI framework, but I really haven't had the time to optimize anything yet.
> --snip--
> This solution works really well for my problem, but it's half-assed in two ways.
> 1) It only allows for asynchronous client transports (as in the case of the XMLHttpRequest object) and not on the server side (with messages coming back in a non-sequential order).
> 2) I'm not sure how to solve the client library issues. Right now, I've moved the core classes (those required on the client (GWT) side of things) into com.facebook.thrift.gwt, while keeping everything else where they are. This allows the GWT compiler to translate com.facebook.thrift.gwt.* while using the same jar both on the client and server. This is not very elegant for people not using GWT (which I suppose is 99.99% of the audience) but short of maintaining two separate Java client libraries, I'm not sure how to solve this issue.
> The attached patch is only for the compiler, and does not produce compilable client code without the modified client library. Just wanted to get some input before producing a somewhat committable patch. Comments? Ideas?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (THRIFT-137) Asynchronous client transports
Posted by "Fredrik Hedberg (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/THRIFT-137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12645802#action_12645802 ]
Fredrik Hedberg commented on THRIFT-137:
----------------------------------------
And if anybody dare to try it, compile the Thrift Java library with 'GWT_HOME=/usr/local/... ant compile-gwt dist' and generate your client code with 'thrift --gen java:beans,async example.thrift'.
final Repository.AsyncIface client = (Repository.AsyncIface) GWT
.create(Repository.AsyncIface.class);
button.addClickListener(new ClickListener() {
public void onClick(Widget sender) {
try {
client.get_document("http://www.host.com/document.html",
new TAsyncCallback<Document>() {
public void onFailure(Throwable throwable) {
Window.alert("Boom!");
}
public void onSuccess(Document result) {
dialogLabel.setText("Success (" + result.getUri() + "): "
+ result.getContent());
dialogBox.center();
dialogBox.show();
}
});
} catch (Exception e) {
}
}
});
> Asynchronous client transports
> ------------------------------
>
> Key: THRIFT-137
> URL: https://issues.apache.org/jira/browse/THRIFT-137
> Project: Thrift
> Issue Type: New Feature
> Components: Compiler (Java), Library (Java)
> Reporter: Fredrik Hedberg
> Priority: Minor
> Attachments: GWTHelper.java, thrift-compiler-gwt-path, thrift-gwt-2.diff, thrift-gwt-3.diff, thrift-gwt-4.diff, thrift-gwt.diff
>
>
> As previously discussed on the mailinglist, using Thrift from Google Web Toolkit (GWT) applications (AJAX) would be nice, as it does not only allow you to consume existing Thrift services from GWT applications, but also means that you now can write GWT-consumable RPC services in any language (and say host them on Google Appengine) that are practically source-code compatible with the official GWT RPC framework.
> Doing this presents two challanges:
> 1) The GWT compiler only supports a subset of the JRE libraries (luckily, this is rather easy to work around).
> 2) As the A in AJAX hints, the only way of doing RPC is asynchronously, something not supported by Thrift, by using the XMLHttpRequest object in the browser.
> Here's what I've done (an excerpt from the mailing-list):
> --snip--
> 1) Created a stripped down jar of Thrift, axed most protocol, transport and server implementations, in order to get a JavaScript-translatable version of Thrift. I did not need to change any of the base Thrift classes, nor modify the compiler for GWT to translate the structs, but I might have missed something here (Mathias?).
> 2) Added an option for the Thrift Java compiler to generate asynchronous service interfaces and client proxies. This is manifested as:
> public class Repository {
> public interface Iface {
> public Document get_document(String uri) throws TException;
> public int get_count() throws TException;
> }
> public interface AsyncIface {
> public void get_document(String uri, TAsyncCallback<Document>
> callback) throws TException;
> public void get_count(TAsyncCallback<Integer> callback) throws TException;
> }
> ...
> This is done in line with GWT's RPC framework and gives the developer the standard synchronous interface to implement on the server side (I use it with embedded Jetty in a daemon) and an asynchonous interface to use in the GWT client. AsyncCallback<T> just has a plain onSuccess(T result) method.
> 3) Implemented a client transport using GWT's RequestBuilder (the XmlHttpRequest abstraction) that executes the TAsyncCallback asynchronously when the response has been received.
> 4) Modified the JSONProtocol slightly to be fully JavaScript-translatable. This could probably be more efficiently done by using GWT's JSNI framework, but I really haven't had the time to optimize anything yet.
> --snip--
> This solution works really well for my problem, but it's half-assed in two ways.
> 1) It only allows for asynchronous client transports (as in the case of the XMLHttpRequest object) and not on the server side (with messages coming back in a non-sequential order).
> 2) I'm not sure how to solve the client library issues. Right now, I've moved the core classes (those required on the client (GWT) side of things) into com.facebook.thrift.gwt, while keeping everything else where they are. This allows the GWT compiler to translate com.facebook.thrift.gwt.* while using the same jar both on the client and server. This is not very elegant for people not using GWT (which I suppose is 99.99% of the audience) but short of maintaining two separate Java client libraries, I'm not sure how to solve this issue.
> The attached patch is only for the compiler, and does not produce compilable client code without the modified client library. Just wanted to get some input before producing a somewhat committable patch. Comments? Ideas?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (THRIFT-137) Asynchronous client transports
Posted by "Fredrik Hedberg (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/THRIFT-137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Fredrik Hedberg updated THRIFT-137:
-----------------------------------
Attachment: thrift-gwt.diff
> Asynchronous client transports
> ------------------------------
>
> Key: THRIFT-137
> URL: https://issues.apache.org/jira/browse/THRIFT-137
> Project: Thrift
> Issue Type: Improvement
> Components: Compiler (Java)
> Reporter: Fredrik Hedberg
> Priority: Minor
> Attachments: thrift-gwt.diff
>
>
> As previously discussed on the mailinglist, using Thrift from Google Web Toolkit (GWT) applications (AJAX) would be nice, as it does not only allow you to consume existing Thrift services from GWT applications, but also means that you now can write GWT-consumable RPC services in any language (and say host them on Google Appengine) that are practically source-code compatible with the official GWT RPC framework.
> Doing this presents two challanges:
> 1) The GWT compiler only supports a subset of the JRE libraries (luckily, this is rather easy to work around).
> 2) As the A in AJAX hints, the only way of doing RPC is asynchronously, something not supported by Thrift, by using the XMLHttpRequest object in the browser.
> Here's what I've done (an excerpt from the mailing-list):
> --snip--
> 1) Created a stripped down jar of Thrift, axed most protocol, transport and server implementations, in order to get a JavaScript-translatable version of Thrift. I did not need to change any of the base Thrift classes, nor modify the compiler for GWT to translate the structs, but I might have missed something here (Mathias?).
> 2) Added an option for the Thrift Java compiler to generate asynchronous service interfaces and client proxies. This is manifested as:
> public class Repository {
> public interface Iface {
> public Document get_document(String uri) throws TException;
> public int get_count() throws TException;
> }
> public interface AsyncIface {
> public void get_document(String uri, TAsyncCallback<Document>
> callback) throws TException;
> public void get_count(TAsyncCallback<Integer> callback) throws TException;
> }
> ...
> This is done in line with GWT's RPC framework and gives the developer the standard synchronous interface to implement on the server side (I use it with embedded Jetty in a daemon) and an asynchonous interface to use in the GWT client. AsyncCallback<T> just has a plain onSuccess(T result) method.
> 3) Implemented a client transport using GWT's RequestBuilder (the XmlHttpRequest abstraction) that executes the TAsyncCallback asynchronously when the response has been received.
> 4) Modified the JSONProtocol slightly to be fully JavaScript-translatable. This could probably be more efficiently done by using GWT's JSNI framework, but I really haven't had the time to optimize anything yet.
> --snip--
> This solution works really well for my problem, but it's half-assed in two ways.
> 1) It only allows for asynchronous client transports (as in the case of the XMLHttpRequest object) and not on the server side (with messages coming back in a non-sequential order).
> 2) I'm not sure how to solve the client library issues. Right now, I've moved the core classes (those required on the client (GWT) side of things) into com.facebook.thrift.gwt, while keeping everything else where they are. This allows the GWT compiler to translate com.facebook.thrift.gwt.* while using the same jar both on the client and server. This is not very elegant for people not using GWT (which I suppose is 99.99% of the audience) but short of maintaining two separate Java client libraries, I'm not sure how to solve this issue.
> The attached patch is only for the compiler, and does not produce compilable client code without the modified client library. Just wanted to get some input before producing a somewhat committable patch. Comments? Ideas?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.