cross domain GWT-RPC

[janick reynders]

Hi All,

In my current project it would simplify things a lot if we could do
cross-domain GWT-RPC calls. If this would be possible we could use GWT
to create a module that can be easily included (as wel as css-styled)
in third party websites that don't have GWT installed, providing
functionality to these websites that is implemented in our
application. (ie the third party website can become the host page)

I recently did a spike implementation (prototype) to explore this, and
managed to create an application that does GWT-RPC over dynamic script
tags instead of XHR. This prototype used used the technique described
in "Using GWT for JSON Mashups" ( http://code.google.com/support/bin/answer.py?answer=65632&topic=11368
) and a modified ProxyCreator and RemoteServiceServlet to achieve its
goal.

The only downside that I see at this point is the URL length
restriction in some browsers.

In the prototype application, I did not change GWT code and make
custom GWT builds, but I learned that this meant that I had to
duplicate some code from GWT (for example because of class/method
visibility). Therefor I think it could be done in a cleaner (a lot
more reuse) way if this functionality could be added to GWT directly.

Is there any interest in such a contribution to GWT?

--Janick

[Miroslav Pokorny]

Sounds pretty look. Ideally the transport should be separated from the rpc driver, that way users can pick from XHR, script tags, IFRAMES etc.

[janick reynders]

Miroslav: do you mean like providing another marker interface instead
of RemoteService or (maybe better) an annotation specifying the
transport?

Is this a question that I should ask in the google-web-toolkit group
or in the gwt issue tracker? I'd like to find out if this
functionality has a chance of getting into the GWT codebase if I
contribute it (assuming the "making gwt better" guidelines are
followed).

--Janick


On 7 jan, 21:32, "Miroslav Pokorny" <miroslav.poko...@gmail.com>
wrote:

> Sounds pretty look. Ideally the transport should be separated from the rpc
> driver, that way users can pick from XHR, script tags, IFRAMES etc.
>

> On Jan 8, 2008 1:17 AM, janick reynders <janick.reynd...@gmail.com> wrote:
>
>
>
>
>
> > Hi All,
>
> > In my current project it would simplify things a lot if we could do
> > cross-domain GWT-RPC calls. If this would be possible we could use GWT
> > to create a module that can be easily included (as wel as css-styled)
> > in third party websites that don't have GWT installed, providing
> > functionality to these websites that is implemented in our
> > application. (ie the third party website can become the host page)
>
> > I recently did a spike implementation (prototype) to explore this, and
> > managed to create an application that does GWT-RPC over dynamic script
> > tags instead of XHR. This prototype used used the technique described
> > in "Using GWT for JSON Mashups" (
> >http://code.google.com/support/bin/answer.py?answer=65632&topic=11368
> > ) and a modified ProxyCreator and RemoteServiceServlet to achieve its
> > goal.
>
> > The only downside that I see at this point is the URL length
> > restriction in some browsers.
>
> > In the prototype application, I did not change GWT code and make
> > custom GWT builds, but I learned that this meant that I had to
> > duplicate some code from GWT (for example because of class/method
> > visibility). Therefor I think it could be done in a cleaner (a lot
> > more reuse) way if this functionality could be added to GWT directly.
>
> > Is there any interest in such a contribution to GWT?
>
> > --Janick
>

> --
> mP

[Miroslav Pokorny]

On Jan 8, 2008 8:43 PM, janick reynders <janick....@gmail.com> wrote:

Miroslav: do you mean like providing another marker interface instead
of RemoteService or (maybe better) an annotation specifying the
transport?

Any client in the end doesnt really care or need to know how the data is being serialized or transported to the target. It should just work. As an rpc i client the only thing a developers code should care about is setting the url of the service followed by invoking the service method with parameters. At a guess i would say which transport to use is prolly something that can and should at compile time - so a annotation should suffice. There is no need to make these details available at runtime. I cant see why any client would want or need to know at runtime how the rpc is being delivered. Maybe there are usecases but they would i imagine be the exception or pretty rare compared to devs just wanting it to work.

Is this a question that I should ask in the google-web-toolkit group
or in the gwt issue tracker? I'd like to find out if this
functionality has a chance of getting into the GWT codebase if I
contribute it (assuming the "making gwt better" guidelines are
followed).

Imho you are doing the right thing and asking in here. Lets hope more ppl vote for this.


here GWTC is for contributtions, GWT is for general help.

[janick reynders]

On 8 jan, 10:51, "Miroslav Pokorny" <miroslav.poko...@gmail.com>
wrote:

> Any client in the end doesnt really care or need to know how the data is
> being serialized or transported to the target. It should just work. As an
> rpc i client the only thing a developers code should care about is setting
> the url of the service followed by invoking the service method with
> parameters. At a guess i would say which transport to use is prolly
> something that can and should at compile time - so a annotation should
> suffice. There is no need to make these details available at runtime. I cant
> see why any client would want or need to know at runtime how the rpc is
> being delivered.
>

Yes I agree 100%

--Janick

[janick reynders]

> On 8 jan, 10:51, "Miroslav Pokorny" <miroslav.poko...@gmail.com>
> wrote:
>
> > At a guess i would say which transport to use is prolly
> > something that can and should at compile time - so a annotation should
> > suffice.

I made changes against the 1.4 release that makes this functionality
possible (following GWT coding guidelines, unit tested). A service can
be invoked cross-domain by annotating the service class with
"@gwt.RPCTransport ScriptTag". I can submit the patch if there is
interest for this.

--Janick

[John Tamplin]

On Jan 14, 2008 10:00 AM, janick reynders <janick....@gmail.com> wrote:

I made changes against the 1.4 release that makes this functionality

possible (following GWT coding guidelines, unit tested). A service can
be invoked cross-domain by annotating the service class with
"@gwt.RPCTransport ScriptTag". I can submit the patch if there is
interest for this.

Great, please post the patch.  Have you submitted a CLA?

--
John A. Tamplin
Software Engineer, Google

[janick reynders]

On 14 jan, 16:15, "John Tamplin" <j...@google.com> wrote:
>
> Great, please post the patch. Have you submitted a CLA?
>

No not yet. I'll get it signed asap. On that matter: should schedule A
just list the names of the designated employees?

--Janick

[janick reynders]

The email address "cla-sub...@google.com" doesn't seem to work:

"Delivery to the following recipient failed permanently:

cla-sub...@google.com

Technical details of permanent failure:
PERM_FAILURE: SMTP Error (state 13): 553 5.5.3 <cla-
submi...@google.com>... Invalid"

Is there another email address I can send the signed CLA to?

--Janick

[janick reynders]

I posted the patch: http://groups.google.com/group/Google-Web-Toolkit-Contributors/browse_thread/thread/94c18c4ec158070c