> I doubt you're going to have 500+ open Ajax requests on a single serverAgreed. The ability to not tie up a thread is not a major issue (for us at
> (the point at which the threading issues become issues). So, I wouldn't
> want to mess around too much with trying to make some requests served Async
> and some synchronous. It's likely to be more damaging to performance and
> maintainability than it's worth.
> There's an existing mechanism that I introduced as part of Wiring that
least), just a nice side effect. But using Futures provide other benefits
not directly tied to scalability. Ie. they compose nicely and clearly
demarcate when async stuff is happening etc
I've been working on mechanisms for unifying Lift's rendering with
> Streams/Futures and Comet as part of Lift 3.0. I'm noodling right now on aSounds interesting. Is this in the lift_30 branch?
> mechanism that's not as heavy-weight as Lift's comet stuff, but still
> allows push as data becomes available. I'm also noodling with browser-based
> Actors that do asynchronous messaging between the client and the server.
> I'll work this requirement (sending the results of futures back to the
> browser) into my design thoughts.
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.