[Lift] Re: Concurrent Web Service Requests?

2009-10-02 Thread Derek Chen-Becker
I'm a little late to the game, but my vote would be for keeping all lift-related attrs under the lift prefix. I don't feel like we need to attach any meaning the the lift prefix other than that it's something that lift will use. Derek On Thu, Oct 1, 2009 at 9:39 PM, marius d.

[Lift] Re: Concurrent Web Service Requests?

2009-10-01 Thread marius d.
Well I said what I had to say. My problem is not really the prefix name but the existence of other prefixes then lift, that are interpreted by lift. It's just how I see things now and nothing on this thread provided sufficient arguments to convince me otherwise ... not much else for me to do if

[Lift] Re: Concurrent Web Service Requests?

2009-10-01 Thread David Pollak
Marius, I have a ton of respect for your opinion and I appreciate your analysis. I have been following this thread and thinking, what does the lift: prefix mean? In my mind, it means this thing will be changed based on evaluating some code. So, using the lift: prefix for something that also

[Lift] Re: Concurrent Web Service Requests?

2009-10-01 Thread marius d.
David, Thank you very much for your kind words. Personally I don't see any reason why the lift prefix can not also have the semantic for enriching the context you described this thing will be changed based on evaluating some code.. These are after all attributes and attributes to me are about

[Lift] Re: Concurrent Web Service Requests?

2009-10-01 Thread Naftoli Gugenheim
Have we been misunderstanding each other? The lift prefix can be a snippet invocation as an attribute too. Thus the fact that it's an attribute does not separate reserved names from user space snippet names. - marius d.marius.dan...@gmail.com wrote: David,

[Lift] Re: Concurrent Web Service Requests?

2009-09-30 Thread Kevin Wright
I thought there were issues here because anything starting lift: gets executed as a snippet. I'm still for an eval: prefix, as these proposals all relate to how a page is evaluated. On Wed, Sep 30, 2009 at 5:34 AM, marius d. marius.dan...@gmail.com wrote: lift is already a reserved prefix

[Lift] Re: Concurrent Web Service Requests?

2009-09-30 Thread marius d.
On Sep 30, 8:23 am, Kevin Wright kev.lee.wri...@googlemail.com wrote: I thought there were issues here because anything starting lift: gets executed as a snippet. Correct BUT lift:par or lift:parallel attributes are also applicable to snippets context. They determine the snippet's execution

[Lift] Re: Concurrent Web Service Requests?

2009-09-30 Thread Naftoli Gugenheim
Could you elaborate on why adding a new prefix may not be a good idea? And is it better or worse than having it unprefixed? - marius d.marius.dan...@gmail.com wrote: On Sep 30, 8:23 am, Kevin Wright kev.lee.wri...@googlemail.com wrote: I thought there

[Lift] Re: Concurrent Web Service Requests?

2009-09-30 Thread marius d.
It has been debated many times in slightly different contexts. To me it is more about clarity. We add a new prefix now, tomorrow add another one and so on. People would have to remember what goes where and mix things up. To me lift prefix is enough and quite clear. It is more than just s snippet

[Lift] Re: Concurrent Web Service Requests?

2009-09-30 Thread Naftoli Gugenheim
I think everyone agrees in concept, that an arbitrary prefix sets a bad precendent, which is why it is no longer do:par. But on the other hand, if the part after lift: is either a reserved word or a user word--a snippet name--then the more reserved words, the more you limit snippet names.

[Lift] Re: Concurrent Web Service Requests?

2009-09-29 Thread marius d.
I realize that I may be a little late here but I do have second thoughts about liftx prefix. Yeah, I'm not a big fan of it. I understand that these attributes are not really snippets or built is snippets but is this an enough reason to introduce a new prefix? Personally I don't think so.

[Lift] Re: Concurrent Web Service Requests?

2009-09-29 Thread Naftoli Gugenheim
So what is your proposal? Am I interpreting you correctly that you are for a prefix of 'lift'? And it will be a reserved suffix? - marius d.marius.dan...@gmail.com wrote: I realize that I may be a little late here but I do have second thoughts about liftx

[Lift] Re: Concurrent Web Service Requests?

2009-09-29 Thread marius d.
lift is already a reserved prefix for snippets. So I'd stay with simply lift prefix for these attributes as well. Br's, Marius On Sep 29, 11:11 pm, Naftoli Gugenheim naftoli...@gmail.com wrote: So what is your proposal? Am I interpreting you correctly that you are for a prefix of 'lift'? And

[Lift] Re: Concurrent Web Service Requests?

2009-09-25 Thread David Pollak
On Thu, Sep 24, 2009 at 11:33 AM, Naftoli Gugenheim naftoli...@gmail.comwrote: If you like the idea of having them all as attributes but don't like the idea of using a single attribute ('xx:eager_eval=true xx:parallel=true' rather than 'xx:eval=eager parallel' as I suggested, where xx is the

[Lift] Re: Concurrent Web Service Requests?

2009-09-25 Thread Timothy Perrett
Looks great :-) can't wait to see this in master. Cheers, Tim Sent from my iPhone On 25 Sep 2009, at 18:02, David Pollak feeder.of.the.be...@gmail.com wrote: On Thu, Sep 24, 2009 at 11:33 AM, Naftoli Gugenheim naftoli...@gmail.com wrote: If you like the idea of having them all as

[Lift] Re: Concurrent Web Service Requests?

2009-09-24 Thread David Pollak
On Wed, Sep 23, 2009 at 11:43 AM, Naftoli Gugenheim naftoli...@gmail.comwrote: What do you mean by as a normal snippet? The parallel snippet processing is implemented deep inside LiftSession. It's not a snippet. All the lift:xxx/ tags, even those with defaults built into Lift, are

[Lift] Re: Concurrent Web Service Requests?

2009-09-24 Thread Ross Mellgren
My 2 cents, I'm not sure I'm a fan of do: namespace, though I agree it would be nice to have a common one. Maybe snippet:parallel, snippet:eager_eval? -Ross On Sep 24, 2009, at 12:46 PM, David Pollak wrote: On Wed, Sep 23, 2009 at 11:43 AM, Naftoli Gugenheim naftoli...@gmail.com wrote:

[Lift] Re: Concurrent Web Service Requests?

2009-09-24 Thread Naftoli Gugenheim
If you like the idea of having them all as attributes but don't like the idea of using a single attribute ('xx:eager_eval=true xx:parallel=true' rather than 'xx:eval=eager parallel' as I suggested, where xx is the prefix to be chosen) then maybe the prefix should be 'eval'. As far as ajax

[Lift] Re: Concurrent Web Service Requests?

2009-09-23 Thread Jeppe Nejsum Madsen
David Pollak feeder.of.the.be...@gmail.com writes: I've added code (it's in review board right now) that will automatically farm any snippet with the do:lazy='true' attribute set. So, lift:foo/ will execute the foo snippet inline. lift:foo do:lazy=true/ will execute the foo snippet in

[Lift] Re: Concurrent Web Service Requests?

2009-09-23 Thread Naftoli Gugenheim
Could that be changed to lift:concurrent or lift:par etc. (see email on scala-user from Marting Odersky mentioned the future use of 'seq' and 'par' in concurrent collections)? Why use a different prefix than everything else built in to lift? And 'lazy' is arguably not what's happening. Thanks.

[Lift] Re: Concurrent Web Service Requests?

2009-09-23 Thread Timothy Perrett
+1 I think naftoli's suggestion is a good one and we should go with something that carries a better semantic. Cheers, Tim On Sep 23, 11:59 am, Naftoli Gugenheim naftoli...@gmail.com wrote: Could that be changed to lift:concurrent or lift:par etc. (see email on scala-user from Marting

[Lift] Re: Concurrent Web Service Requests?

2009-09-23 Thread David Pollak
On Tue, Sep 22, 2009 at 11:52 PM, Jeppe Nejsum Madsen je...@ingolfs.dkwrote: David Pollak feeder.of.the.be...@gmail.com writes: I've added code (it's in review board right now) that will automatically farm any snippet with the do:lazy='true' attribute set. So, lift:foo/ will execute

[Lift] Re: Concurrent Web Service Requests?

2009-09-23 Thread David Pollak
On Wed, Sep 23, 2009 at 3:59 AM, Naftoli Gugenheim naftoli...@gmail.comwrote: Could that be changed to lift:concurrent or lift:par etc. (see email on scala-user from Marting Odersky mentioned the future use of 'seq' and 'par' in concurrent collections)? Why use a different prefix than

[Lift] Re: Concurrent Web Service Requests?

2009-09-23 Thread Naftoli Gugenheim
A snippet attribute can be invoked with something other than lift:snippet=Class.method? There's a short syntax? What is it? What was used for the feature that inserts a snippet asynchronously via Ajax? My concern is that as more features are thought up and added they shouldn't all end up with

[Lift] Re: Concurrent Web Service Requests?

2009-09-23 Thread Timothy Perrett
That's yet more sensible talking... +1 Btw, are there any issues with using undefined attribute namespaces? Or is that just for elements? Cheers, Tim Sent from my iPhone On 23 Sep 2009, at 18:40, Naftoli Gugenheim naftoli...@gmail.com wrote: A snippet attribute can be invoked with

[Lift] Re: Concurrent Web Service Requests?

2009-09-23 Thread David Pollak
On Wed, Sep 23, 2009 at 10:40 AM, Naftoli Gugenheim naftoli...@gmail.comwrote: A snippet attribute can be invoked with something other than lift:snippet=Class.method? There's a short syntax? What is it? There may be a short syntax (e.g., lift:Class.method) in the future. What was used for

[Lift] Re: Concurrent Web Service Requests?

2009-09-23 Thread Naftoli Gugenheim
What do you mean by as a normal snippet? That you will nest your snippet inside a special snippet? To me it seems worthwhile to have a consistency between the two syntax-wise, since they have some common denominator semantics-wise. Actually, maybe throw in eager_eval to the mix. Maybe we could

[Lift] Re: Concurrent Web Service Requests?

2009-09-22 Thread David Pollak
I've added code (it's in review board right now) that will automatically farm any snippet with the do:lazy='true' attribute set. So, lift:foo/ will execute the foo snippet inline. lift:foo do:lazy=true/ will execute the foo snippet in parallel and join the result back to page before its

[Lift] Re: Concurrent Web Service Requests?

2009-09-21 Thread David Pollak
Lift only uses event-based Actors for supporting CometActors. All parts of the standard HTTP request/response cycle (except for the CometActors) are handled on a single thread. Having a single thread handle an HTTP request is not materially less efficient in terms of multi-core CPU utilization

[Lift] Re: Concurrent Web Service Requests?

2009-09-21 Thread espeed
On Sep 21, 2:33 pm, David Pollak feeder.of.the.be...@gmail.com wrote: Lift only uses event-based Actors for supporting CometActors.  All parts of the standard HTTP request/response cycle (except for the CometActors) are handled on a single thread. Hi David - Thanks for your quick response.

[Lift] Re: Concurrent Web Service Requests?

2009-09-21 Thread David Pollak
On Mon, Sep 21, 2009 at 1:19 PM, espeed james.thorn...@gmail.com wrote: On Sep 21, 2:33 pm, David Pollak feeder.of.the.be...@gmail.com wrote: Lift only uses event-based Actors for supporting CometActors. All parts of the standard HTTP request/response cycle (except for the CometActors)

[Lift] Re: Concurrent Web Service Requests?

2009-09-21 Thread espeed
On Sep 21, 4:29 pm, David Pollak feeder.of.the.be...@gmail.com wrote: Well.. there's a Java way of doing exactly that: fork/join on a thread.   Seehttp://java.sun.com/javase/6/docs/api/java/lang/Thread.html But to weave this into the page rendering, there would be some work required on your

[Lift] Re: Concurrent Web Service Requests?

2009-09-21 Thread David Pollak
On Mon, Sep 21, 2009 at 3:19 PM, espeed james.thorn...@gmail.com wrote: On Sep 21, 4:29 pm, David Pollak feeder.of.the.be...@gmail.com wrote: Well.. there's a Java way of doing exactly that: fork/join on a thread. Seehttp://java.sun.com/javase/6/docs/api/java/lang/Thread.html But to