[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. marius.dan...@gmail.com wrote:


 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 about meta-data on how lift will change
 markup.

 I will do what you suggested hopefully by next Monday ... and this
 time using the proper process ;)

 Br's,
 Marius

 On Oct 1, 7:03 pm, David Pollak feeder.of.the.be...@gmail.com wrote:
  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 means
 this
  modifies the meaning of this snippet invocation presents
  something discordant to me.
 
  With that being said, I'm going to hand the decision to you.  I trust
 your
  decisions and have concerns about my own instincts when it comes to
 naming.
 
  Please update the code to reflect what you think it should be and merge
 it
  into master.
 
  Thanks,
 
  David
 
  On Thu, Oct 1, 2009 at 5:58 AM, marius d. marius.dan...@gmail.com
 wrote:
 
   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 majority and especially DPP thinks
   otherwise. It is what it is I guess.
 
   Br's,
   Marius
 
   On Oct 1, 4:18 am, Naftoli Gugenheim naftoli...@gmail.com wrote:
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.
   (Should S.mapSnippet(parallel, ...) throw an exception?)
So we have these two considerations on either end of the spectrum.
   Arguably, liftx as a prefix satisfies both--it is sufficiently
 generic to
   include almost any special attribute that may be added, it clearly
 spells
   out extended lift attribute, and on the other hand it keeps reserved
 lift
   attributes separate from the user's snippet namespace.
Now let's bear in mind that this is all only relevant in the future,
 when
   lift: attributes indeed will be interpreted as lift:snippet=... is
 now. At
   that point it might make sense for the explicit :snippet format to be
 moved
   to the liftx prefix-- liftx:snippet=... --for the same reason, not to
   encroach on the snippet namespace.
 
-
 
marius d.marius.dan...@gmail.com wrote:
 
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 thingy. It tells the user hey this thing is
telling the framework something and the framework is doing something
with it. It is separating framework xml markup from the actual xhtml
markup. Having a single reserved prefix promotes clarity and keeps
things simple and rather intuitive.
 
I'm not in favor of using unprefixed attributes like
par=something (btw I really don't like par naming :) ...) because
unprefixed attributes should be only standard xhtml ones or the ones
that user explicitly specifies it. So lift:parallel=true or
lift:async=true should be just fine.
 
Br's,
Marius
 
On Sep 30, 8:05 pm, Naftoli Gugenheim naftoli...@gmail.com wrote:
 
 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 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
 semantics.
 So I'm still questioning the need for a new prefix.
 
  I'm still for an eval: prefix, as these proposals all relate to
 how 

[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 majority and especially DPP thinks
otherwise. It is what it is I guess.

Br's,
Marius

On Oct 1, 4:18 am, Naftoli Gugenheim naftoli...@gmail.com wrote:
 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. (Should 
 S.mapSnippet(parallel, ...) throw an exception?)
 So we have these two considerations on either end of the spectrum. Arguably, 
 liftx as a prefix satisfies both--it is sufficiently generic to include 
 almost any special attribute that may be added, it clearly spells out 
 extended lift attribute, and on the other hand it keeps reserved lift 
 attributes separate from the user's snippet namespace.
 Now let's bear in mind that this is all only relevant in the future, when 
 lift: attributes indeed will be interpreted as lift:snippet=... is now. At 
 that point it might make sense for the explicit :snippet format to be moved 
 to the liftx prefix-- liftx:snippet=... --for the same reason, not to 
 encroach on the snippet namespace.

 -

 marius d.marius.dan...@gmail.com wrote:

 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 thingy. It tells the user hey this thing is
 telling the framework something and the framework is doing something
 with it. It is separating framework xml markup from the actual xhtml
 markup. Having a single reserved prefix promotes clarity and keeps
 things simple and rather intuitive.

 I'm not in favor of using unprefixed attributes like
 par=something (btw I really don't like par naming :) ...) because
 unprefixed attributes should be only standard xhtml ones or the ones
 that user explicitly specifies it. So lift:parallel=true or
 lift:async=true should be just fine.

 Br's,
 Marius

 On Sep 30, 8:05 pm, Naftoli Gugenheim naftoli...@gmail.com wrote:

  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 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 semantics.
  So I'm still questioning the need for a new prefix.

   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 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 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 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. Historically lift reserved prefix names
were heavily debated and argued and this is a little sensitive area.

But the good news is that I may be the only one feeling this way about
this and everyone else likes it so I'm just a negligible minority.

Br's,
Marius

On Sep 25, 12:02 pm, David Pollak feeder.of.the.be...@gmail.com
wrote:

 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
  prefix to be chosen) then maybe the prefix should be 'eval'.

 I've changed the code to:
 liftx:eager_eval=true
 liftx:par=true | liftx:parallel=true

 The reasons for not combining them:

    - 

[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 means this
modifies the meaning of this snippet invocation presents
something discordant to me.

With that being said, I'm going to hand the decision to you.  I trust your
decisions and have concerns about my own instincts when it comes to naming.

Please update the code to reflect what you think it should be and merge it
into master.

Thanks,

David

On Thu, Oct 1, 2009 at 5:58 AM, marius d. marius.dan...@gmail.com wrote:


 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 majority and especially DPP thinks
 otherwise. It is what it is I guess.

 Br's,
 Marius

 On Oct 1, 4:18 am, Naftoli Gugenheim naftoli...@gmail.com wrote:
  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.
 (Should S.mapSnippet(parallel, ...) throw an exception?)
  So we have these two considerations on either end of the spectrum.
 Arguably, liftx as a prefix satisfies both--it is sufficiently generic to
 include almost any special attribute that may be added, it clearly spells
 out extended lift attribute, and on the other hand it keeps reserved lift
 attributes separate from the user's snippet namespace.
  Now let's bear in mind that this is all only relevant in the future, when
 lift: attributes indeed will be interpreted as lift:snippet=... is now. At
 that point it might make sense for the explicit :snippet format to be moved
 to the liftx prefix-- liftx:snippet=... --for the same reason, not to
 encroach on the snippet namespace.
 
  -
 
  marius d.marius.dan...@gmail.com wrote:
 
  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 thingy. It tells the user hey this thing is
  telling the framework something and the framework is doing something
  with it. It is separating framework xml markup from the actual xhtml
  markup. Having a single reserved prefix promotes clarity and keeps
  things simple and rather intuitive.
 
  I'm not in favor of using unprefixed attributes like
  par=something (btw I really don't like par naming :) ...) because
  unprefixed attributes should be only standard xhtml ones or the ones
  that user explicitly specifies it. So lift:parallel=true or
  lift:async=true should be just fine.
 
  Br's,
  Marius
 
  On Sep 30, 8:05 pm, Naftoli Gugenheim naftoli...@gmail.com wrote:
 
   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 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 semantics.
   So I'm still questioning the need for a new prefix.
 
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 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 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 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. Historically lift reserved prefix
 names
 were heavily debated and argued and this is a little sensitive
 area.
 
 But the good news is that 

[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 about meta-data on how lift will change
markup.

I will do what you suggested hopefully by next Monday ... and this
time using the proper process ;)

Br's,
Marius

On Oct 1, 7:03 pm, David Pollak feeder.of.the.be...@gmail.com wrote:
 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 means this
 modifies the meaning of this snippet invocation presents
 something discordant to me.

 With that being said, I'm going to hand the decision to you.  I trust your
 decisions and have concerns about my own instincts when it comes to naming.

 Please update the code to reflect what you think it should be and merge it
 into master.

 Thanks,

 David

 On Thu, Oct 1, 2009 at 5:58 AM, marius d. marius.dan...@gmail.com wrote:

  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 majority and especially DPP thinks
  otherwise. It is what it is I guess.

  Br's,
  Marius

  On Oct 1, 4:18 am, Naftoli Gugenheim naftoli...@gmail.com wrote:
   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.
  (Should S.mapSnippet(parallel, ...) throw an exception?)
   So we have these two considerations on either end of the spectrum.
  Arguably, liftx as a prefix satisfies both--it is sufficiently generic to
  include almost any special attribute that may be added, it clearly spells
  out extended lift attribute, and on the other hand it keeps reserved lift
  attributes separate from the user's snippet namespace.
   Now let's bear in mind that this is all only relevant in the future, when
  lift: attributes indeed will be interpreted as lift:snippet=... is now. At
  that point it might make sense for the explicit :snippet format to be moved
  to the liftx prefix-- liftx:snippet=... --for the same reason, not to
  encroach on the snippet namespace.

   -

   marius d.marius.dan...@gmail.com wrote:

   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 thingy. It tells the user hey this thing is
   telling the framework something and the framework is doing something
   with it. It is separating framework xml markup from the actual xhtml
   markup. Having a single reserved prefix promotes clarity and keeps
   things simple and rather intuitive.

   I'm not in favor of using unprefixed attributes like
   par=something (btw I really don't like par naming :) ...) because
   unprefixed attributes should be only standard xhtml ones or the ones
   that user explicitly specifies it. So lift:parallel=true or
   lift:async=true should be just fine.

   Br's,
   Marius

   On Sep 30, 8:05 pm, Naftoli Gugenheim naftoli...@gmail.com wrote:

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 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 semantics.
So I'm still questioning the need for a new prefix.

 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 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'? 

[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,

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 about meta-data on how lift will change
markup.

I will do what you suggested hopefully by next Monday ... and this
time using the proper process ;)

Br's,
Marius

On Oct 1, 7:03 pm, David Pollak feeder.of.the.be...@gmail.com wrote:
 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 means this
 modifies the meaning of this snippet invocation presents
 something discordant to me.

 With that being said, I'm going to hand the decision to you.  I trust your
 decisions and have concerns about my own instincts when it comes to naming.

 Please update the code to reflect what you think it should be and merge it
 into master.

 Thanks,

 David

 On Thu, Oct 1, 2009 at 5:58 AM, marius d. marius.dan...@gmail.com wrote:

  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 majority and especially DPP thinks
  otherwise. It is what it is I guess.

  Br's,
  Marius

  On Oct 1, 4:18 am, Naftoli Gugenheim naftoli...@gmail.com wrote:
   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.
  (Should S.mapSnippet(parallel, ...) throw an exception?)
   So we have these two considerations on either end of the spectrum.
  Arguably, liftx as a prefix satisfies both--it is sufficiently generic to
  include almost any special attribute that may be added, it clearly spells
  out extended lift attribute, and on the other hand it keeps reserved lift
  attributes separate from the user's snippet namespace.
   Now let's bear in mind that this is all only relevant in the future, when
  lift: attributes indeed will be interpreted as lift:snippet=... is now. At
  that point it might make sense for the explicit :snippet format to be moved
  to the liftx prefix-- liftx:snippet=... --for the same reason, not to
  encroach on the snippet namespace.

   -

   marius d.marius.dan...@gmail.com wrote:

   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 thingy. It tells the user hey this thing is
   telling the framework something and the framework is doing something
   with it. It is separating framework xml markup from the actual xhtml
   markup. Having a single reserved prefix promotes clarity and keeps
   things simple and rather intuitive.

   I'm not in favor of using unprefixed attributes like
   par=something (btw I really don't like par naming :) ...) because
   unprefixed attributes should be only standard xhtml ones or the ones
   that user explicitly specifies it. So lift:parallel=true or
   lift:async=true should be just fine.

   Br's,
   Marius

   On Sep 30, 8:05 pm, Naftoli Gugenheim naftoli...@gmail.com wrote:

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 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 semantics.
So I'm still questioning the need for a new prefix.

 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 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 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 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 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. Historically lift reserved prefix names
 were heavily debated and argued and this is a little sensitive area.

 But the good news is that I may be the only one feeling this way about
 this and everyone else likes it so I'm just a negligible minority.

 Br's,
 Marius

 On Sep 25, 12:02 pm, David Pollak feeder.of.the.be...@gmail.com
 wrote:

  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
   prefix to be chosen) then maybe the prefix should be 'eval'.

  I've changed the code to:
  liftx:eager_eval=true
  liftx:par=true | liftx:parallel=true

  The reasons for not combining them:

     - They are evaluated in different parts of the code, thus eager/parallel
     doesn't make sense from a code path perspective
     - I am reserving the value of liftx:par for future implementation to
     allow farming the snippet evaluation to another mechanism.  Right now, 
  it's
     hard-coded to use LiftActors.  I can see a time when it would work with 
  Akka
     actors or some other parallelization mechanism

   As far as ajax evaluation I'm not sure I'm understanding. Could you 
   show
   me what you're thinking?
   If I have a snippet
   lift:MySnippet /
   what would be the syntax to have it inserted via ajax?

  lift:Ajax !-- the snippet name will not be ajax, but you get the idea 
  --
    lift:MySnippet/
  /lift:Ajax

   -
   Ross Mellgrendri...@gmail.com wrote:

   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:

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 implemented as snippets and
are invoked with normal snippet invocation mechanisms.

That you will nest your snippet inside a special snippet?

There is no special snippet.  I used the word normal to highlight
that it's functionality that doesn't require a change to LiftSession
or other parts of Lift to function correctly.

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 have
one eval or lift:eval or liftx:eval or whatever attribute, which can
contain a space separated list of specifiers--eager, ajax, parellel.

Anything that's prefixed with lift: is a snippet.  I'm open to
unifying eager_eval and do:lazy (or do:par or do:parallel) into a
unified namespace.

-
David Pollakfeeder.of.the.be...@gmail.com wrote:

On Wed, Sep 23, 2009 at 10:40 AM, Naftoli Gugenheim 
   naftoli...@gmail.com
wrote:

 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 the feature that inserts a snippet
asynchronously via
 Ajax?

That feature isn't done yet, but that feature is likely to be done
as a
normal snippet.

 My concern is that as more features are thought up and added they
shouldn't
 all end up with different prefixes.
 Also, if the prefix is nothing special I would go with the more
verbose
 parallel because otherwise it's not obvious what it does. If
it's prefixed
 with lift: at least you know it's a lift tag and 

[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 semantics.
So I'm still questioning the need for a new prefix.


 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 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 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 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. Historically lift reserved prefix names
  were heavily debated and argued and this is a little sensitive area.

  But the good news is that I may be the only one feeling this way about
  this and everyone else likes it so I'm just a negligible minority.

  Br's,
  Marius

  On Sep 25, 12:02 pm, David Pollak feeder.of.the.be...@gmail.com
  wrote:

   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
prefix to be chosen) then maybe the prefix should be 'eval'.

   I've changed the code to:
   liftx:eager_eval=true
   liftx:par=true | liftx:parallel=true

   The reasons for not combining them:

      - They are evaluated in different parts of the code, thus 
   eager/parallel
      doesn't make sense from a code path perspective
      - I am reserving the value of liftx:par for future implementation to
      allow farming the snippet evaluation to another mechanism.  Right 
   now, it's
      hard-coded to use LiftActors.  I can see a time when it would work 
   with Akka
      actors or some other parallelization mechanism

As far as ajax evaluation I'm not sure I'm understanding. Could you 
show
me what you're thinking?
If I have a snippet
lift:MySnippet /
what would be the syntax to have it inserted via ajax?

   lift:Ajax !-- the snippet name will not be ajax, but you get the idea 
   --
     lift:MySnippet/
   /lift:Ajax

-
Ross Mellgrendri...@gmail.com wrote:

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:

 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 implemented as snippets and
 are invoked with normal snippet invocation mechanisms.

 That you will nest your snippet inside a special snippet?

 There is no special snippet.  I used the word normal to highlight
 that it's functionality that doesn't require a change to LiftSession
 or other parts of Lift to function correctly.

 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 have
 one eval or lift:eval or liftx:eval or whatever attribute, which can
 contain a space separated list of specifiers--eager, ajax, parellel.

 Anything that's prefixed with lift: is a snippet.  I'm open to
 unifying eager_eval and do:lazy (or do:par or do:parallel) into a
 unified namespace.

 -
 David Pollakfeeder.of.the.be...@gmail.com wrote:

 On Wed, Sep 23, 2009 at 10:40 AM, Naftoli Gugenheim 
naftoli...@gmail.com
 wrote:

  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 the feature that inserts a snippet
 asynchronously via
  Ajax?

 That feature isn't done yet, but that feature is likely to be done
 as a

[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 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 semantics.
So I'm still questioning the need for a new prefix.


 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 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 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 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. Historically lift reserved prefix names
  were heavily debated and argued and this is a little sensitive area.

  But the good news is that I may be the only one feeling this way about
  this and everyone else likes it so I'm just a negligible minority.

  Br's,
  Marius

  On Sep 25, 12:02 pm, David Pollak feeder.of.the.be...@gmail.com
  wrote:

   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
prefix to be chosen) then maybe the prefix should be 'eval'.

   I've changed the code to:
   liftx:eager_eval=true
   liftx:par=true | liftx:parallel=true

   The reasons for not combining them:

      - They are evaluated in different parts of the code, thus 
   eager/parallel
      doesn't make sense from a code path perspective
      - I am reserving the value of liftx:par for future implementation to
      allow farming the snippet evaluation to another mechanism.  Right 
   now, it's
      hard-coded to use LiftActors.  I can see a time when it would work 
   with Akka
      actors or some other parallelization mechanism

As far as ajax evaluation I'm not sure I'm understanding. Could you 
show
me what you're thinking?
If I have a snippet
lift:MySnippet /
what would be the syntax to have it inserted via ajax?

   lift:Ajax !-- the snippet name will not be ajax, but you get the idea 
   --
     lift:MySnippet/
   /lift:Ajax

-
Ross Mellgrendri...@gmail.com wrote:

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:

 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 implemented as snippets and
 are invoked with normal snippet invocation mechanisms.

 That you will nest your snippet inside a special snippet?

 There is no special snippet.  I used the word normal to highlight
 that it's functionality that doesn't require a change to LiftSession
 or other parts of Lift to function correctly.

 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 have
 one eval or lift:eval or liftx:eval or whatever attribute, which can
 contain a space separated list of specifiers--eager, ajax, parellel.

 Anything that's prefixed with lift: is a snippet.  I'm open to
 unifying eager_eval and do:lazy (or do:par or do:parallel) into a
 unified namespace.

 -
 David Pollakfeeder.of.the.be...@gmail.com wrote:

 On Wed, Sep 23, 2009 at 10:40 AM, Naftoli Gugenheim 
naftoli...@gmail.com
 wrote:

  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] 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 thingy. It tells the user hey this thing is
telling the framework something and the framework is doing something
with it. It is separating framework xml markup from the actual xhtml
markup. Having a single reserved prefix promotes clarity and keeps
things simple and rather intuitive.

I'm not in favor of using unprefixed attributes like
par=something (btw I really don't like par naming :) ...) because
unprefixed attributes should be only standard xhtml ones or the ones
that user explicitly specifies it. So lift:parallel=true or
lift:async=true should be just fine.


Br's,
Marius

On Sep 30, 8:05 pm, Naftoli Gugenheim naftoli...@gmail.com wrote:
 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 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 semantics.
 So I'm still questioning the need for a new prefix.



  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 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 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 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. Historically lift reserved prefix names
   were heavily debated and argued and this is a little sensitive area.

   But the good news is that I may be the only one feeling this way about
   this and everyone else likes it so I'm just a negligible minority.

   Br's,
   Marius

   On Sep 25, 12:02 pm, David Pollak feeder.of.the.be...@gmail.com
   wrote:

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
 prefix to be chosen) then maybe the prefix should be 'eval'.

I've changed the code to:
liftx:eager_eval=true
liftx:par=true | liftx:parallel=true

The reasons for not combining them:

   - They are evaluated in different parts of the code, thus 
eager/parallel
   doesn't make sense from a code path perspective
   - I am reserving the value of liftx:par for future implementation to
   allow farming the snippet evaluation to another mechanism.  Right 
now, it's
   hard-coded to use LiftActors.  I can see a time when it would work 
with Akka
   actors or some other parallelization mechanism

 As far as ajax evaluation I'm not sure I'm understanding. Could 
 you show
 me what you're thinking?
 If I have a snippet
 lift:MySnippet /
 what would be the syntax to have it inserted via ajax?

lift:Ajax !-- the snippet name will not be ajax, but you get the 
idea --
  lift:MySnippet/
/lift:Ajax

 -
 Ross Mellgrendri...@gmail.com wrote:

 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:

  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 implemented as snippets 
  and
  are invoked with normal snippet invocation mechanisms.

  That you will nest your snippet inside a special snippet?

  There is no special snippet.  I used the 

[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. (Should 
S.mapSnippet(parallel, ...) throw an exception?) 
So we have these two considerations on either end of the spectrum. Arguably, 
liftx as a prefix satisfies both--it is sufficiently generic to include 
almost any special attribute that may be added, it clearly spells out 
extended lift attribute, and on the other hand it keeps reserved lift 
attributes separate from the user's snippet namespace.
Now let's bear in mind that this is all only relevant in the future, when lift: 
attributes indeed will be interpreted as lift:snippet=... is now. At that 
point it might make sense for the explicit :snippet format to be moved to the 
liftx prefix-- liftx:snippet=... --for the same reason, not to encroach on 
the snippet namespace.


-
marius d.marius.dan...@gmail.com wrote:


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 thingy. It tells the user hey this thing is
telling the framework something and the framework is doing something
with it. It is separating framework xml markup from the actual xhtml
markup. Having a single reserved prefix promotes clarity and keeps
things simple and rather intuitive.

I'm not in favor of using unprefixed attributes like
par=something (btw I really don't like par naming :) ...) because
unprefixed attributes should be only standard xhtml ones or the ones
that user explicitly specifies it. So lift:parallel=true or
lift:async=true should be just fine.


Br's,
Marius

On Sep 30, 8:05 pm, Naftoli Gugenheim naftoli...@gmail.com wrote:
 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 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 semantics.
 So I'm still questioning the need for a new prefix.



  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 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 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 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. Historically lift reserved prefix names
   were heavily debated and argued and this is a little sensitive area.

   But the good news is that I may be the only one feeling this way about
   this and everyone else likes it so I'm just a negligible minority.

   Br's,
   Marius

   On Sep 25, 12:02 pm, David Pollak feeder.of.the.be...@gmail.com
   wrote:

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
 prefix to be chosen) then maybe the prefix should be 'eval'.

I've changed the code to:
liftx:eager_eval=true
liftx:par=true | liftx:parallel=true

The reasons for not combining them:

   - They are evaluated in different parts of the code, thus 
eager/parallel
   doesn't make sense from a code path perspective
   - I am reserving the value of liftx:par for future implementation to
   allow farming the snippet evaluation to another mechanism.  Right 
now, it's
   hard-coded to use LiftActors.  I can see a time when it would work 
with Akka
   actors or some other parallelization mechanism

 As far as ajax evaluation I'm not sure I'm understanding. Could 
 you show
 me what 

[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. Historically lift reserved prefix names
were heavily debated and argued and this is a little sensitive area.

But the good news is that I may be the only one feeling this way about
this and everyone else likes it so I'm just a negligible minority.

Br's,
Marius

On Sep 25, 12:02 pm, David Pollak feeder.of.the.be...@gmail.com
wrote:
 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
  prefix to be chosen) then maybe the prefix should be 'eval'.

 I've changed the code to:
 liftx:eager_eval=true
 liftx:par=true | liftx:parallel=true

 The reasons for not combining them:

    - They are evaluated in different parts of the code, thus eager/parallel
    doesn't make sense from a code path perspective
    - I am reserving the value of liftx:par for future implementation to
    allow farming the snippet evaluation to another mechanism.  Right now, it's
    hard-coded to use LiftActors.  I can see a time when it would work with 
 Akka
    actors or some other parallelization mechanism



  As far as ajax evaluation I'm not sure I'm understanding. Could you show
  me what you're thinking?
  If I have a snippet
  lift:MySnippet /
  what would be the syntax to have it inserted via ajax?

 lift:Ajax !-- the snippet name will not be ajax, but you get the idea --
   lift:MySnippet/
 /lift:Ajax





  -
  Ross Mellgrendri...@gmail.com wrote:

  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:

   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 implemented as snippets and
   are invoked with normal snippet invocation mechanisms.

   That you will nest your snippet inside a special snippet?

   There is no special snippet.  I used the word normal to highlight
   that it's functionality that doesn't require a change to LiftSession
   or other parts of Lift to function correctly.

   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 have
   one eval or lift:eval or liftx:eval or whatever attribute, which can
   contain a space separated list of specifiers--eager, ajax, parellel.

   Anything that's prefixed with lift: is a snippet.  I'm open to
   unifying eager_eval and do:lazy (or do:par or do:parallel) into a
   unified namespace.

   -
   David Pollakfeeder.of.the.be...@gmail.com wrote:

   On Wed, Sep 23, 2009 at 10:40 AM, Naftoli Gugenheim 
  naftoli...@gmail.com
   wrote:

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 the feature that inserts a snippet
   asynchronously via
Ajax?

   That feature isn't done yet, but that feature is likely to be done
   as a
   normal snippet.

My concern is that as more features are thought up and added they
   shouldn't
all end up with different prefixes.
Also, if the prefix is nothing special I would go with the more
   verbose
parallel because otherwise it's not obvious what it does. If
   it's prefixed
with lift: at least you know it's a lift tag and you can look it
   up
somewhere or ask on the list etc. But if you come back to some old
   template
that says do:par you may be left clueless.

-
David Pollakfeeder.of.the.be...@gmail.com wrote:

On Wed, Sep 23, 2009 at 3: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 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.

We're using a different prefix because if we use a lift:xxx
   prefix, the
snippet execution 

[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 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. Historically lift reserved prefix names
were heavily debated and argued and this is a little sensitive area.

But the good news is that I may be the only one feeling this way about
this and everyone else likes it so I'm just a negligible minority.

Br's,
Marius

On Sep 25, 12:02 pm, David Pollak feeder.of.the.be...@gmail.com
wrote:
 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
  prefix to be chosen) then maybe the prefix should be 'eval'.

 I've changed the code to:
 liftx:eager_eval=true
 liftx:par=true | liftx:parallel=true

 The reasons for not combining them:

    - They are evaluated in different parts of the code, thus eager/parallel
    doesn't make sense from a code path perspective
    - I am reserving the value of liftx:par for future implementation to
    allow farming the snippet evaluation to another mechanism.  Right now, it's
    hard-coded to use LiftActors.  I can see a time when it would work with 
 Akka
    actors or some other parallelization mechanism



  As far as ajax evaluation I'm not sure I'm understanding. Could you show
  me what you're thinking?
  If I have a snippet
  lift:MySnippet /
  what would be the syntax to have it inserted via ajax?

 lift:Ajax !-- the snippet name will not be ajax, but you get the idea --
   lift:MySnippet/
 /lift:Ajax





  -
  Ross Mellgrendri...@gmail.com wrote:

  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:

   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 implemented as snippets and
   are invoked with normal snippet invocation mechanisms.

   That you will nest your snippet inside a special snippet?

   There is no special snippet.  I used the word normal to highlight
   that it's functionality that doesn't require a change to LiftSession
   or other parts of Lift to function correctly.

   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 have
   one eval or lift:eval or liftx:eval or whatever attribute, which can
   contain a space separated list of specifiers--eager, ajax, parellel.

   Anything that's prefixed with lift: is a snippet.  I'm open to
   unifying eager_eval and do:lazy (or do:par or do:parallel) into a
   unified namespace.

   -
   David Pollakfeeder.of.the.be...@gmail.com wrote:

   On Wed, Sep 23, 2009 at 10:40 AM, Naftoli Gugenheim 
  naftoli...@gmail.com
   wrote:

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 the feature that inserts a snippet
   asynchronously via
Ajax?

   That feature isn't done yet, but that feature is likely to be done
   as a
   normal snippet.

My concern is that as more features are thought up and added they
   shouldn't
all end up with different prefixes.
Also, if the prefix is nothing special I would go with the more
   verbose
parallel because otherwise it's not obvious what it does. If
   it's prefixed
with lift: at least you know it's a lift tag and you can look it
   up
somewhere or ask on the list etc. But if you come back to some old
   template
that says do:par you may be left clueless.

-
David Pollakfeeder.of.the.be...@gmail.com wrote:

On Wed, Sep 23, 2009 at 3: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 Odersky mentioned the future use of
   'seq' and
'par'
 in concurrent collections)?
 Why use a 

[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 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 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. Historically lift reserved prefix names
 were heavily debated and argued and this is a little sensitive area.

 But the good news is that I may be the only one feeling this way about
 this and everyone else likes it so I'm just a negligible minority.

 Br's,
 Marius

 On Sep 25, 12:02 pm, David Pollak feeder.of.the.be...@gmail.com
 wrote:

  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
   prefix to be chosen) then maybe the prefix should be 'eval'.

  I've changed the code to:
  liftx:eager_eval=true
  liftx:par=true | liftx:parallel=true

  The reasons for not combining them:

     - They are evaluated in different parts of the code, thus eager/parallel
     doesn't make sense from a code path perspective
     - I am reserving the value of liftx:par for future implementation to
     allow farming the snippet evaluation to another mechanism.  Right now, 
  it's
     hard-coded to use LiftActors.  I can see a time when it would work with 
  Akka
     actors or some other parallelization mechanism

   As far as ajax evaluation I'm not sure I'm understanding. Could you show
   me what you're thinking?
   If I have a snippet
   lift:MySnippet /
   what would be the syntax to have it inserted via ajax?

  lift:Ajax !-- the snippet name will not be ajax, but you get the idea --
    lift:MySnippet/
  /lift:Ajax

   -
   Ross Mellgrendri...@gmail.com wrote:

   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:

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 implemented as snippets and
are invoked with normal snippet invocation mechanisms.

That you will nest your snippet inside a special snippet?

There is no special snippet.  I used the word normal to highlight
that it's functionality that doesn't require a change to LiftSession
or other parts of Lift to function correctly.

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 have
one eval or lift:eval or liftx:eval or whatever attribute, which can
contain a space separated list of specifiers--eager, ajax, parellel.

Anything that's prefixed with lift: is a snippet.  I'm open to
unifying eager_eval and do:lazy (or do:par or do:parallel) into a
unified namespace.

-
David Pollakfeeder.of.the.be...@gmail.com wrote:

On Wed, Sep 23, 2009 at 10:40 AM, Naftoli Gugenheim 
   naftoli...@gmail.com
wrote:

 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 the feature that inserts a snippet
asynchronously via
 Ajax?

That feature isn't done yet, but that feature is likely to be done
as a
normal snippet.

 My concern is that as more features are thought up and added they
shouldn't
 all end up with different prefixes.
 Also, if the prefix is nothing special I would go with the more
verbose
 parallel because otherwise it's not obvious what it does. If
it's prefixed
 with lift: at least you know it's a lift tag and you can look it
up
 somewhere or ask on the list etc. But if you come back to some old
template
 that says do:par you may be left clueless.

 -
 David Pollakfeeder.of.the.be...@gmail.com wrote:

 On Wed, Sep 

[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
 prefix to be chosen) then maybe the prefix should be 'eval'.


I've changed the code to:
liftx:eager_eval=true
liftx:par=true | liftx:parallel=true

The reasons for not combining them:

   - They are evaluated in different parts of the code, thus eager/parallel
   doesn't make sense from a code path perspective
   - I am reserving the value of liftx:par for future implementation to
   allow farming the snippet evaluation to another mechanism.  Right now, it's
   hard-coded to use LiftActors.  I can see a time when it would work with Akka
   actors or some other parallelization mechanism





 As far as ajax evaluation I'm not sure I'm understanding. Could you show
 me what you're thinking?
 If I have a snippet
 lift:MySnippet /
 what would be the syntax to have it inserted via ajax?


lift:Ajax !-- the snippet name will not be ajax, but you get the idea --
  lift:MySnippet/
/lift:Ajax



 -
 Ross Mellgrendri...@gmail.com wrote:

 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:
 
  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 implemented as snippets and
  are invoked with normal snippet invocation mechanisms.
 
  That you will nest your snippet inside a special snippet?
 
  There is no special snippet.  I used the word normal to highlight
  that it's functionality that doesn't require a change to LiftSession
  or other parts of Lift to function correctly.
 
  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 have
  one eval or lift:eval or liftx:eval or whatever attribute, which can
  contain a space separated list of specifiers--eager, ajax, parellel.
 
  Anything that's prefixed with lift: is a snippet.  I'm open to
  unifying eager_eval and do:lazy (or do:par or do:parallel) into a
  unified namespace.
 
 
 
  -
  David Pollakfeeder.of.the.be...@gmail.com wrote:
 
  On Wed, Sep 23, 2009 at 10:40 AM, Naftoli Gugenheim 
 naftoli...@gmail.com
  wrote:
 
  
   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 the feature that inserts a snippet
  asynchronously via
   Ajax?
  
 
  That feature isn't done yet, but that feature is likely to be done
  as a
  normal snippet.
 
 
   My concern is that as more features are thought up and added they
  shouldn't
   all end up with different prefixes.
   Also, if the prefix is nothing special I would go with the more
  verbose
   parallel because otherwise it's not obvious what it does. If
  it's prefixed
   with lift: at least you know it's a lift tag and you can look it
  up
   somewhere or ask on the list etc. But if you come back to some old
  template
   that says do:par you may be left clueless.
  
  
   -
   David Pollakfeeder.of.the.be...@gmail.com wrote:
  
   On Wed, Sep 23, 2009 at 3: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 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.
   
  
  
   We're using a different prefix because if we use a lift:xxx
  prefix, the
   snippet execution machinery will be invoked on the attribute and
  we don't
   want that.
  
   I'm cool with do:par unless anyone has a better suggestion.
  
   Thanks,
  
   David
  
  
Thanks.
   
   
-
Jeppe Nejsum Madsenje...@ingolfs.dk wrote:
   
   
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
  parallel and
join
 the result back to page 

[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 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'.

 I've changed the code to:
 liftx:eager_eval=true
 liftx:par=true | liftx:parallel=true

 The reasons for not combining them:
 They are evaluated in different parts of the code, thus eager/ 
 parallel doesn't make sense from a code path perspective
 I am reserving the value of liftx:par for future implementation to  
 allow farming the snippet evaluation to another mechanism.  Right  
 now, it's hard-coded to use LiftActors.  I can see a time when it  
 would work with Akka actors or some other parallelization mechanism



 As far as ajax evaluation I'm not sure I'm understanding. Could  
 you show me what you're thinking?
 If I have a snippet
 lift:MySnippet /
 what would be the syntax to have it inserted via ajax?

 lift:Ajax !-- the snippet name will not be ajax, but you get the  
 idea --
   lift:MySnippet/
 /lift:Ajax


 -
 Ross Mellgrendri...@gmail.com wrote:

 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:
 
  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 implemented as snippets and
  are invoked with normal snippet invocation mechanisms.
 
  That you will nest your snippet inside a special snippet?
 
  There is no special snippet.  I used the word normal to highlight
  that it's functionality that doesn't require a change to LiftSession
  or other parts of Lift to function correctly.
 
  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 have
  one eval or lift:eval or liftx:eval or whatever attribute, which can
  contain a space separated list of specifiers--eager, ajax, parellel.
 
  Anything that's prefixed with lift: is a snippet.  I'm open to
  unifying eager_eval and do:lazy (or do:par or do:parallel) into a
  unified namespace.
 
 
 
  -
  David Pollakfeeder.of.the.be...@gmail.com wrote:
 
  On Wed, Sep 23, 2009 at 10:40 AM, Naftoli Gugenheim naftoli...@gmail.com
  wrote:
 
  
   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 the feature that inserts a snippet
  asynchronously via
   Ajax?
  
 
  That feature isn't done yet, but that feature is likely to be done
  as a
  normal snippet.
 
 
   My concern is that as more features are thought up and added they
  shouldn't
   all end up with different prefixes.
   Also, if the prefix is nothing special I would go with the more
  verbose
   parallel because otherwise it's not obvious what it does. If
  it's prefixed
   with lift: at least you know it's a lift tag and you can look it
  up
   somewhere or ask on the list etc. But if you come back to some old
  template
   that says do:par you may be left clueless.
  
  
   -
   David Pollakfeeder.of.the.be...@gmail.com wrote:
  
   On Wed, Sep 23, 2009 at 3: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 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.
   
  
  
   We're using a different prefix because if we use a lift:xxx
  prefix, the
   snippet execution machinery will be invoked on the attribute and
  we don't
   want that.
  
   I'm cool with do:par unless anyone has a better suggestion.
  
   Thanks,
  
   David
  
  
Thanks.
   
   
-
Jeppe Nejsum Madsenje...@ingolfs.dk wrote:
   
   
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.


[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 implemented as snippets and are invoked with normal
snippet invocation mechanisms.


 That you will nest your snippet inside a special snippet?


There is no special snippet.  I used the word normal to highlight that
it's functionality that doesn't require a change to LiftSession or other
parts of Lift to function correctly.


 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 have one
 eval or lift:eval or liftx:eval or whatever attribute, which can contain a
 space separated list of specifiers--eager, ajax, parellel.


Anything that's prefixed with lift: is a snippet.  I'm open to unifying
eager_eval and do:lazy (or do:par or do:parallel) into a unified namespace.




 -
 David Pollakfeeder.of.the.be...@gmail.com wrote:

 On Wed, Sep 23, 2009 at 10:40 AM, Naftoli Gugenheim naftoli...@gmail.com
 wrote:

 
  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 the feature that inserts a snippet asynchronously via
  Ajax?
 

 That feature isn't done yet, but that feature is likely to be done as a
 normal snippet.


  My concern is that as more features are thought up and added they
 shouldn't
  all end up with different prefixes.
  Also, if the prefix is nothing special I would go with the more verbose
  parallel because otherwise it's not obvious what it does. If it's
 prefixed
  with lift: at least you know it's a lift tag and you can look it up
  somewhere or ask on the list etc. But if you come back to some old
 template
  that says do:par you may be left clueless.
 
 
  -
  David Pollakfeeder.of.the.be...@gmail.com wrote:
 
  On Wed, Sep 23, 2009 at 3: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 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.
  
 
 
  We're using a different prefix because if we use a lift:xxx prefix, the
  snippet execution machinery will be invoked on the attribute and we don't
  want that.
 
  I'm cool with do:par unless anyone has a better suggestion.
 
  Thanks,
 
  David
 
 
   Thanks.
  
  
   -
   Jeppe Nejsum Madsenje...@ingolfs.dk wrote:
  
  
   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 parallel
 and
   join
the result back to page before its rendered.
  
   Very nice! In what context is the snippet executed? I assume that
   all timeout handling, errors etc should be handled by the snippet just
   as in the non-lazy fashion?
  
   /Jeppe
  
  
  
  
   
  
 
 
  --
  Lift, the simply functional web framework http://liftweb.net
  Beginning Scala http://www.apress.com/book/view/1430219890
  Follow me: http://twitter.com/dpp
  Surf the harmonics
 
 
 
  
 


 --
 Lift, the simply functional web framework http://liftweb.net
 Beginning Scala http://www.apress.com/book/view/1430219890
 Follow me: http://twitter.com/dpp
 Surf the harmonics



 



-- 
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Surf the harmonics

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---



[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:

 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 implemented as snippets and  
 are invoked with normal snippet invocation mechanisms.

 That you will nest your snippet inside a special snippet?

 There is no special snippet.  I used the word normal to highlight  
 that it's functionality that doesn't require a change to LiftSession  
 or other parts of Lift to function correctly.

 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 have  
 one eval or lift:eval or liftx:eval or whatever attribute, which can  
 contain a space separated list of specifiers--eager, ajax, parellel.

 Anything that's prefixed with lift: is a snippet.  I'm open to  
 unifying eager_eval and do:lazy (or do:par or do:parallel) into a  
 unified namespace.



 -
 David Pollakfeeder.of.the.be...@gmail.com wrote:

 On Wed, Sep 23, 2009 at 10:40 AM, Naftoli Gugenheim naftoli...@gmail.com 
 wrote:

 
  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 the feature that inserts a snippet  
 asynchronously via
  Ajax?
 

 That feature isn't done yet, but that feature is likely to be done  
 as a
 normal snippet.


  My concern is that as more features are thought up and added they  
 shouldn't
  all end up with different prefixes.
  Also, if the prefix is nothing special I would go with the more  
 verbose
  parallel because otherwise it's not obvious what it does. If  
 it's prefixed
  with lift: at least you know it's a lift tag and you can look it  
 up
  somewhere or ask on the list etc. But if you come back to some old  
 template
  that says do:par you may be left clueless.
 
 
  -
  David Pollakfeeder.of.the.be...@gmail.com wrote:
 
  On Wed, Sep 23, 2009 at 3: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 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.
  
 
 
  We're using a different prefix because if we use a lift:xxx  
 prefix, the
  snippet execution machinery will be invoked on the attribute and  
 we don't
  want that.
 
  I'm cool with do:par unless anyone has a better suggestion.
 
  Thanks,
 
  David
 
 
   Thanks.
  
  
   -
   Jeppe Nejsum Madsenje...@ingolfs.dk wrote:
  
  
   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  
 parallel and
   join
the result back to page before its rendered.
  
   Very nice! In what context is the snippet executed? I assume that
   all timeout handling, errors etc should be handled by the  
 snippet just
   as in the non-lazy fashion?
  
   /Jeppe
  
  
  
  
   
  
 
 
  --
  Lift, the simply functional web framework http://liftweb.net
  Beginning Scala http://www.apress.com/book/view/1430219890
  Follow me: http://twitter.com/dpp
  Surf the harmonics
 
 
 
  
 


 --
 Lift, the simply functional web framework http://liftweb.net
 Beginning Scala http://www.apress.com/book/view/1430219890
 Follow me: http://twitter.com/dpp
 Surf the harmonics







 -- 
 Lift, the simply functional web framework http://liftweb.net
 Beginning Scala http://www.apress.com/book/view/1430219890
 Follow me: http://twitter.com/dpp
 Surf the harmonics

 


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---



[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 evaluation I'm not sure I'm understanding. Could you show me 
what you're thinking?
If I have a snippet
lift:MySnippet /
what would be the syntax to have it inserted via ajax?

-
Ross Mellgrendri...@gmail.com wrote:

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:

 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 implemented as snippets and  
 are invoked with normal snippet invocation mechanisms.

 That you will nest your snippet inside a special snippet?

 There is no special snippet.  I used the word normal to highlight  
 that it's functionality that doesn't require a change to LiftSession  
 or other parts of Lift to function correctly.

 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 have  
 one eval or lift:eval or liftx:eval or whatever attribute, which can  
 contain a space separated list of specifiers--eager, ajax, parellel.

 Anything that's prefixed with lift: is a snippet.  I'm open to  
 unifying eager_eval and do:lazy (or do:par or do:parallel) into a  
 unified namespace.



 -
 David Pollakfeeder.of.the.be...@gmail.com wrote:

 On Wed, Sep 23, 2009 at 10:40 AM, Naftoli Gugenheim naftoli...@gmail.com 
 wrote:

 
  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 the feature that inserts a snippet  
 asynchronously via
  Ajax?
 

 That feature isn't done yet, but that feature is likely to be done  
 as a
 normal snippet.


  My concern is that as more features are thought up and added they  
 shouldn't
  all end up with different prefixes.
  Also, if the prefix is nothing special I would go with the more  
 verbose
  parallel because otherwise it's not obvious what it does. If  
 it's prefixed
  with lift: at least you know it's a lift tag and you can look it  
 up
  somewhere or ask on the list etc. But if you come back to some old  
 template
  that says do:par you may be left clueless.
 
 
  -
  David Pollakfeeder.of.the.be...@gmail.com wrote:
 
  On Wed, Sep 23, 2009 at 3: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 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.
  
 
 
  We're using a different prefix because if we use a lift:xxx  
 prefix, the
  snippet execution machinery will be invoked on the attribute and  
 we don't
  want that.
 
  I'm cool with do:par unless anyone has a better suggestion.
 
  Thanks,
 
  David
 
 
   Thanks.
  
  
   -
   Jeppe Nejsum Madsenje...@ingolfs.dk wrote:
  
  
   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  
 parallel and
   join
the result back to page before its rendered.
  
   Very nice! In what context is the snippet executed? I assume that
   all timeout handling, errors etc should be handled by the  
 snippet just
   as in the non-lazy fashion?
  
   /Jeppe
  
  
  
  
   
  
 
 
  --
  Lift, the simply functional web framework http://liftweb.net
  Beginning Scala http://www.apress.com/book/view/1430219890
  Follow me: http://twitter.com/dpp
  Surf the harmonics
 
 
 
  
 


 --
 Lift, the simply functional web framework http://liftweb.net
 Beginning Scala http://www.apress.com/book/view/1430219890
 Follow me: http://twitter.com/dpp
 Surf the harmonics







 -- 
 Lift, the simply functional web framework http://liftweb.net
 Beginning Scala http://www.apress.com/book/view/1430219890
 Follow me: http://twitter.com/dpp
 Surf the harmonics

 



[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 parallel and join
 the result back to page before its rendered.

Very nice! In what context is the snippet executed? I assume that
all timeout handling, errors etc should be handled by the snippet just
as in the non-lazy fashion?

/Jeppe


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---



[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.


-
Jeppe Nejsum Madsenje...@ingolfs.dk wrote:


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 parallel and join
 the result back to page before its rendered.

Very nice! In what context is the snippet executed? I assume that
all timeout handling, errors etc should be handled by the snippet just
as in the non-lazy fashion?

/Jeppe




--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---



[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 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.

 -

 Jeppe Nejsum Madsenje...@ingolfs.dk wrote:
 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 parallel and join
  the result back to page before its rendered.

 Very nice! In what context is the snippet executed? I assume that
 all timeout handling, errors etc should be handled by the snippet just
 as in the non-lazy fashion?

 /Jeppe
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---



[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 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 rendered.

 Very nice! In what context is the snippet executed? I assume that
 all timeout handling, errors etc should be handled by the snippet just
 as in the non-lazy fashion?


The NodeSeq that the snippet returns is rolled into the rendered page.

The SessionVars are available and bi-directional (set anywhere is visible
anywhere.)  The RequestVars are snapshotted at the time the snippet is
forked so you can see all RequestVars that were set before the snippet
forking, but any subsequent changes by either the main thread or the forked
thread are only visible on that thread.

You may nest forked snippets.

S is valid for parallel snippets (including the request, etc.)



 /Jeppe


 



-- 
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Surf the harmonics

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---



[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 everything else built in to lift? And
 'lazy' is arguably not what's happening.



We're using a different prefix because if we use a lift:xxx prefix, the
snippet execution machinery will be invoked on the attribute and we don't
want that.

I'm cool with do:par unless anyone has a better suggestion.

Thanks,

David


 Thanks.


 -
 Jeppe Nejsum Madsenje...@ingolfs.dk wrote:


 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 parallel and
 join
  the result back to page before its rendered.

 Very nice! In what context is the snippet executed? I assume that
 all timeout handling, errors etc should be handled by the snippet just
 as in the non-lazy fashion?

 /Jeppe




 



-- 
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Surf the harmonics

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---



[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 different prefixes.
Also, if the prefix is nothing special I would go with the more verbose 
parallel because otherwise it's not obvious what it does. If it's prefixed 
with lift: at least you know it's a lift tag and you can look it up somewhere 
or ask on the list etc. But if you come back to some old template that says 
do:par you may be left clueless.


-
David Pollakfeeder.of.the.be...@gmail.com wrote:

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 everything else built in to lift? And
 'lazy' is arguably not what's happening.



We're using a different prefix because if we use a lift:xxx prefix, the
snippet execution machinery will be invoked on the attribute and we don't
want that.

I'm cool with do:par unless anyone has a better suggestion.

Thanks,

David


 Thanks.


 -
 Jeppe Nejsum Madsenje...@ingolfs.dk wrote:


 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 parallel and
 join
  the result back to page before its rendered.

 Very nice! In what context is the snippet executed? I assume that
 all timeout handling, errors etc should be handled by the snippet just
 as in the non-lazy fashion?

 /Jeppe




 



-- 
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Surf the harmonics



--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---



[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 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 different prefixes.
 Also, if the prefix is nothing special I would go with the more  
 verbose parallel because otherwise it's not obvious what it does.  
 If it's prefixed with lift: at least you know it's a lift tag and  
 you can look it up somewhere or ask on the list etc. But if you come  
 back to some old template that says do:par you may be left clueless.


 -
 David Pollakfeeder.of.the.be...@gmail.com wrote:

 On Wed, Sep 23, 2009 at 3: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 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.



 We're using a different prefix because if we use a lift:xxx prefix,  
 the
 snippet execution machinery will be invoked on the attribute and we  
 don't
 want that.

 I'm cool with do:par unless anyone has a better suggestion.

 Thanks,

 David


 Thanks.


 -
 Jeppe Nejsum Madsenje...@ingolfs.dk wrote:


 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  
 parallel and
 join
 the result back to page before its rendered.

 Very nice! In what context is the snippet executed? I assume that
 all timeout handling, errors etc should be handled by the snippet  
 just
 as in the non-lazy fashion?

 /Jeppe








 -- 
 Lift, the simply functional web framework http://liftweb.net
 Beginning Scala http://www.apress.com/book/view/1430219890
 Follow me: http://twitter.com/dpp
 Surf the harmonics



 


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---



[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 the feature that inserts a snippet asynchronously via
 Ajax?


That feature isn't done yet, but that feature is likely to be done as a
normal snippet.


 My concern is that as more features are thought up and added they shouldn't
 all end up with different prefixes.
 Also, if the prefix is nothing special I would go with the more verbose
 parallel because otherwise it's not obvious what it does. If it's prefixed
 with lift: at least you know it's a lift tag and you can look it up
 somewhere or ask on the list etc. But if you come back to some old template
 that says do:par you may be left clueless.


 -
 David Pollakfeeder.of.the.be...@gmail.com wrote:

 On Wed, Sep 23, 2009 at 3: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 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.
 


 We're using a different prefix because if we use a lift:xxx prefix, the
 snippet execution machinery will be invoked on the attribute and we don't
 want that.

 I'm cool with do:par unless anyone has a better suggestion.

 Thanks,

 David


  Thanks.
 
 
  -
  Jeppe Nejsum Madsenje...@ingolfs.dk wrote:
 
 
  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 parallel and
  join
   the result back to page before its rendered.
 
  Very nice! In what context is the snippet executed? I assume that
  all timeout handling, errors etc should be handled by the snippet just
  as in the non-lazy fashion?
 
  /Jeppe
 
 
 
 
  
 


 --
 Lift, the simply functional web framework http://liftweb.net
 Beginning Scala http://www.apress.com/book/view/1430219890
 Follow me: http://twitter.com/dpp
 Surf the harmonics



 



-- 
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Surf the harmonics

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---



[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 have one eval or 
lift:eval or liftx:eval or whatever attribute, which can contain a space 
separated list of specifiers--eager, ajax, parellel.


-
David Pollakfeeder.of.the.be...@gmail.com wrote:

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 the feature that inserts a snippet asynchronously via
 Ajax?


That feature isn't done yet, but that feature is likely to be done as a
normal snippet.


 My concern is that as more features are thought up and added they shouldn't
 all end up with different prefixes.
 Also, if the prefix is nothing special I would go with the more verbose
 parallel because otherwise it's not obvious what it does. If it's prefixed
 with lift: at least you know it's a lift tag and you can look it up
 somewhere or ask on the list etc. But if you come back to some old template
 that says do:par you may be left clueless.


 -
 David Pollakfeeder.of.the.be...@gmail.com wrote:

 On Wed, Sep 23, 2009 at 3: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 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.
 


 We're using a different prefix because if we use a lift:xxx prefix, the
 snippet execution machinery will be invoked on the attribute and we don't
 want that.

 I'm cool with do:par unless anyone has a better suggestion.

 Thanks,

 David


  Thanks.
 
 
  -
  Jeppe Nejsum Madsenje...@ingolfs.dk wrote:
 
 
  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 parallel and
  join
   the result back to page before its rendered.
 
  Very nice! In what context is the snippet executed? I assume that
  all timeout handling, errors etc should be handled by the snippet just
  as in the non-lazy fashion?
 
  /Jeppe
 
 
 
 
  
 


 --
 Lift, the simply functional web framework http://liftweb.net
 Beginning Scala http://www.apress.com/book/view/1430219890
 Follow me: http://twitter.com/dpp
 Surf the harmonics



 



-- 
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Surf the harmonics



--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---



[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 rendered.

This should allow for the use case of going out to ad servers, etc. in
parallel.

On Mon, Sep 21, 2009 at 7:28 PM, espeed james.thorn...@gmail.com wrote:


 On Sep 21, 5:30 pm, David Pollak feeder.of.the.be...@gmail.com
 wrote:
  Threads are used in Scala actors, but only while processing a message
 (actor
  jobs are allocated to threads in a thread pool).  In the case of asking
 your
  external ad server for information, Scala Actors are not going to help
 you
  because they have not been integrated with the JVM's NIO library (NIO ~=
  Unix I/O Select)  Erlang's actor scheduler is IO aware, Scala's is not.

 Googling for Scala actors NIO turned up a recent paper by Matthias
 Schmidt at Sun. There is a section on combing the Scala actor model
 with NIO...

 http://blogs.sun.com/schmidtm/entry/high_performance_tcp_ip_programming

 http://blogs.sun.com/schmidtm/resource/nio-whitepaper/High-Performance-TCPIP-JVM.edit.Final.Formatted.pdf

 I also found this from the upcoming O'Reilly book Programming Scala,
 by Dean Wampler and Alex Payne...

 Chapter 9. Robust, Scalable Concurrency with Actors
 http://programming-scala.labs.oreilly.com/ch09.html

 The open-source Naggati library adds a Scala-friendly layer atop MINA
 that, according to its author, “makes it easy to build protocol
 filters [using a] sequential style”. Essentially, Naggati is a DSL for
 parsing network protocols, with MINA’s powerful NIO abilities under
 the hood.

 - James

 



-- 
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Surf the harmonics

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---



[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 than an event-based Actor.
 The reason for using event-based Actors is to not consume an OS thread
during very long wait periods.  Handing the thread back to the thread pool
means that you're not consuming stack or OS thread-based resources during a
long wait.  Waiting for a query to execute is not a long wait and one would
likely take more of a performance hit to put the thread back into the thread
pool and then get a new thread once the query was done than to block the
thread on IO during the query.

I should point out that JVM-based threading sits directly on top of OS
threading, so you can use as many cores as you have and have a fairness
algorithm that is OS based when you use JVM threads (which Scala does.)
 This contrasts markedly from Python and Ruby (MRI) which cannot use more
than 1 CPU per program (Python because of the global lock and Ruby because
them implementation is pure crap.)  Erlang implements its own threading
model and does better with IO than the JVM because its threading model is
optimized for giving slices to processes that have available IO resources.

When I did a recent benchmark of Lift, I was seeing that all 8 CPUs (4 cores
with 2 hyper-threads each) were being used to serve content because the
requests were parallel and the web container allocated one thread to each
request.

In terms of Lift's use of Scala Actors, it currently does use Scala Actors
for some pieces, but that's changing.  Given the persistent problems with
Scala actors, we are switching over to our own Actor implementation that
avoids Scala Actors' memory retention, etc. problems.

On Mon, Sep 21, 2009 at 12:01 PM, espeed james.thorn...@gmail.com wrote:


 I have been researching Web frameworks that will take advantage of
 multi-core chips, and I'm trying to get a picture for how Lift uses
 Scala's event-based actors for incoming page requests and how an
 application developer would use actors in Lift to make concurrent Web
 service or DB requests.

 From what I understand, incoming page requests are initially handled
 by a thread and then passed off to an event-based actor so the thread
 isn't tied up during the entire page request. For pages that are
 composed of data from multiple Web services or multiple DB calls, the
 page's app developer would create multiple event-based actor requests
 to the different Web services or the DB, depending on where the data
 is located. Correct? -- And if so, is there an example of how to do
 this the Lift way?

 Also, does Lift use the Scala event-based actors library its own?

 Thank you.

 James






 



-- 
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---



[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. If an app developer wants to
parallelize requests to Web services, what is the recommended way to
do this in Lift?

For example, in Rails you might do something like this, where the time
to gather all the data for the page is limited to the longest request
instead of the sum of all requests:

t1 = Thread.new do
  @news_data = NewsClient.getNewsData()
end
t2 = Thread.new do
  @advertisements = AdsClient.getAdsByLocation(zip)
end
t1.join
t2.join

Is there a Lift event-based actor API for this or what is the Lift way
of doing this?

Thanks again.

James



--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---



[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) are
  handled on a single thread.

 Hi David -

 Thanks for your quick response. If an app developer wants to
 parallelize requests to Web services, what is the recommended way to
 do this in Lift?

 For example, in Rails you might do something like this, where the time
 to gather all the data for the page is limited to the longest request
 instead of the sum of all requests:

 t1 = Thread.new do
  @news_data = NewsClient.getNewsData()
 end
 t2 = Thread.new do
  @advertisements = AdsClient.getAdsByLocation(zip)
 end
 t1.join
 t2.join

 Is there a Lift event-based actor API for this or what is the Lift way
 of doing this?


Well.. there's a Java way of doing exactly that: fork/join on a thread.  See
http://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 part: forking the threads early in the page render cycle and then
harvesting their results as each snippet is called.

It might be an interesting feature for Lift, however, to allow for the
forking of snippet execution that would be resolved at the end of page
rendering.  I've added a ticket to add this feature to Lift.



 Thanks again.

 James



 



-- 
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---



[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 part: forking the threads early in the page render cycle and then
 harvesting their results as each snippet is called.

 It might be an interesting feature for Lift, however, to allow for the
 forking of snippet execution that would be resolved at the end of page
 rendering.  I've added a ticket to add this feature to Lift.


Wouldn't it be more efficient to use lightweight actors for this
instead of forking threads?  I have been looking at Erlang too and may
be confused about the Scala actor model because I am new to Scala, but
I thought one of the points of the Scala actor model is not to use
threads in a case like this.

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---



[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 weave this into the page rendering, there would be some work
 required
  on your part: forking the threads early in the page render cycle and then
  harvesting their results as each snippet is called.
 
  It might be an interesting feature for Lift, however, to allow for the
  forking of snippet execution that would be resolved at the end of page
  rendering.  I've added a ticket to add this feature to Lift.


 Wouldn't it be more efficient to use lightweight actors for this
 instead of forking threads?  I have been looking at Erlang too and may
 be confused about the Scala actor model because I am new to Scala, but
 I thought one of the points of the Scala actor model is not to use
 threads in a case like this.


Threads are used in Scala actors, but only while processing a message (actor
jobs are allocated to threads in a thread pool).  In the case of asking your
external ad server for information, Scala Actors are not going to help you
because they have not been integrated with the JVM's NIO library (NIO ~=
Unix I/O Select)  Erlang's actor scheduler is IO aware, Scala's is not.

In terms of efficiency, having an extra 50-100 threads floating around the
JVM is not going to slow anything down noticeably.  Having an extra 2,000
threads will (lots of space for the stack and lots of entries in the
kernel's scheduler).

I expect that the actual Lift implementation will have a plugable design
such that we can use the standard JVM thread pooling or Akka actors (which
may benefit from not using an actual thread during IO waits).



 



-- 
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---