Just my thought on the subject,
At the start of using GWT we also wondered about why there was no
support for continations in GWT and that these Async and Sync
interfaces would cause us a lot of grieve. But it all worked out very
well since we are actually generating the sync and async interfaces
2009/8/4 Rob Heittman
>
> I bet you were into the lovely EJB artifacts too? Ha ha this is strangely
>> reminiscent.
>>
>
> No, I wasn't. Really, I don't see the correlation.
>
Boiler plate, _almost_ duplicate interfaces anyone? "Business methods
defined in the remote interface must be duplica
> I bet you were into the lovely EJB artifacts too? Ha ha this is strangely
> reminiscent.
>
No, I wasn't. Really, I don't see the correlation. But, as you like RPC
abstractions and I don't, I think we can just agree to disagree on religious
principles, and leave it at that. Maybe take it up s
On 4 Aug 2009, at 09:26, Rob Heittman wrote:
> I do just have to say ... I don't use RPC at my shop. It is a
> bit forced, as the underlying RESTful plumbing of the web doesn't map
> tightly onto the RPC paradigm. GWT puts RPC style coding in reach,
> but I still prefer to opt for pure REST. I
While this thread may already have gone on too long in the wrong
place, I do just have to say ... I don't use RPC at my shop. It is a
bit forced, as the underlying RESTful plumbing of the web doesn't map
tightly onto the RPC paradigm. GWT puts RPC style coding in reach,
but I still prefe
On 3 Aug 2009, at 22:22, Bruce Johnson wrote:
> Although it feels less convenient, the async nature of RPC is
> actually valuable for usability. It forces you to think about what
> to do in the application UI while a potentially long-running
> activity is taking place.
I can see how the c
Although it feels less convenient, the async nature of RPC is actually
valuable for usability. It forces you to think about what to do in the
application UI while a potentially long-running activity is taking place.
When you consider that a network round-trip combined with time spent on the
server
On 3 Aug 2009, at 20:53, Miroslav Pokorny wrote:
>
> The Async interface is necessary because one does not want to use sync
> (blocking) rpc calls back to the server. When using blocking calls the
> entire browser freezes which is especially bad give responses arenot
> instantwous.
I was sugges
The Async interface is necessary because one does not want to use sync
(blocking) rpc calls back to the server. When using blocking calls the
entire browser freezes which is especially bad give responses arenot
instantwous.
Hth
On 03/08/2009, at 1:10 AM, jd wrote:
>
> Hi,
>
> I am just ge
Thanks for your response Joel
On 3 Aug 2009, at 20:01, Joel Webber wrote:
> What you're describing is formal support for continuations in the
> compiler. While I'm sure this is theoretically tractable, there are
> several practical issues that are likely to be problematic.
Well yes I guess I
What you're describing is formal support for continuations in the compiler.
While I'm sure this is theoretically tractable, there are several practical
issues that are likely to be problematic.
The first is simply that it makes an asynchronous look synchronous, which is
nice on the surface, but can
I can see that allowing the above would still not solve the async,
single threaded nature of ajax calls.
But there must be some way to reuse the Service interface on the
client.
Perhaps compiling a call to a Service interface could be implemented
in JavaScript like this:
Java:
StockPrice[] pri
12 matches
Mail list logo
