[Lift] Re: Concurrent Web Service Requests?
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. 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 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.
> 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 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. 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 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. wrote:
> >
> > > > > On Sep 30, 8:23 am, Kevin Wright
> > > > > 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 ex
[Lift] Re: Concurrent Web Service Requests?
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. 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 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. 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 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. 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 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. wrote:
>
> > > > On Sep 30, 8:23 am, Kevin Wright
> > > > 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.
> > wrote:
>
> > > >
[Lift] Re: Concurrent Web Service Requests?
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 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. 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 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. 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 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. wrote:
>
> > > > On Sep 30, 8:23 am, Kevin Wright
> > > > 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.
> > 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
> > wrote:
> > > > > >> So what is your propos
[Lift] Re: Concurrent Web Service Requests?
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. 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 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. 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 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. wrote:
> >
> > > On Sep 30, 8:23 am, Kevin Wright
> > > 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.
> 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
> 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. 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 t
[Lift] Re: Concurrent Web Service Requests?
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 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. 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 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. wrote:
>
> > On Sep 30, 8:23 am, Kevin Wright
> > 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.
> > > 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 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. 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
> > > >> wrote:
>
> > > >> > On Thu, Sep 24, 2009 at 11:33 AM, Naftoli Gugenheim
> > > >> > 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
[Lift] Re: Concurrent Web Service Requests?
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. 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 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. wrote:
>
> On Sep 30, 8:23 am, Kevin Wright
> 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. 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 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. 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
> > >> wrote:
>
> > >> > On Thu, Sep 24, 2009 at 11:33 AM, Naftoli Gugenheim
> > >> > 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 eva
[Lift] Re: Concurrent Web Service Requests?
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 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. wrote:
>
> On Sep 30, 8:23 am, Kevin Wright
> 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. 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 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. 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
> > >> wrote:
>
> > >> > On Thu, Sep 24, 2009 at 11:33 AM, Naftoli Gugenheim
> > >> > 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
> > >> > >
> > >> > > what would be the syntax to have it inserted via ajax?
>
> > >> >
> > >> >
> > >> >
>
> > >> > > -
> > >> > > Ross Mellgren 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 tags, even
> > >> > > > those with defaults built into Lift, are implemented as snippets
> > >> > > > and
> > >> > > > are invoked with normal snippet invocation mechanisms.
>
> > >>
[Lift] Re: Concurrent Web Service Requests?
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. wrote:
On Sep 30, 8:23 am, Kevin Wright
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. 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 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. 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
> >> wrote:
>
> >> > On Thu, Sep 24, 2009 at 11:33 AM, Naftoli Gugenheim
> >> > 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
> >> > >
> >> > > what would be the syntax to have it inserted via ajax?
>
> >> >
> >> >
> >> >
>
> >> > > -
> >> > > Ross Mellgren 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 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 Pollak 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] Re: Concurrent Web Service Requests?
On Sep 30, 8:23 am, Kevin Wright
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. 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 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. 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
> >> wrote:
>
> >> > On Thu, Sep 24, 2009 at 11:33 AM, Naftoli Gugenheim
> >> > 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
> >> > >
> >> > > what would be the syntax to have it inserted via ajax?
>
> >> >
> >> >
> >> >
>
> >> > > -
> >> > > Ross Mellgren 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 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 Pollak 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 th
[Lift] Re: Concurrent Web Service Requests?
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. 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 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. 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
>> wrote:
>>
>> > On Thu, Sep 24, 2009 at 11:33 AM, Naftoli Gugenheim
>> > 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
>> > >
>> > > what would be the syntax to have it inserted via ajax?
>>
>> >
>> >
>> >
>>
>> > > -
>> > > Ross Mellgren 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 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 Pollak 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 w
[Lift] Re: Concurrent Web Service Requests?
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 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. 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
> wrote:
>
> > On Thu, Sep 24, 2009 at 11:33 AM, Naftoli Gugenheim
> > 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
> > >
> > > what would be the syntax to have it inserted via ajax?
>
> >
> >
> >
>
> > > -
> > > Ross Mellgren 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 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 Pollak 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.
>
> > > > > --
[Lift] Re: Concurrent Web Service Requests?
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. 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
wrote:
> On Thu, Sep 24, 2009 at 11:33 AM, Naftoli Gugenheim
> 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
> >
> > what would be the syntax to have it inserted via ajax?
>
>
>
>
>
>
>
>
>
> > -
> > Ross Mellgren 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 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 Pollak 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 Pollak 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 concu
[Lift] Re: Concurrent Web Service Requests?
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
wrote:
> On Thu, Sep 24, 2009 at 11:33 AM, Naftoli Gugenheim
> 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
> >
> > what would be the syntax to have it inserted via ajax?
>
>
>
>
>
>
>
>
>
> > -
> > Ross Mellgren 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 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 Pollak 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 Pollak 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 differe
[Lift] Re: Concurrent Web Service Requests?
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
wrote:
>
>
> On Thu, Sep 24, 2009 at 11:33 AM, Naftoli Gugenheim > 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
>
> what would be the syntax to have it inserted via ajax?
>
>
>
>
>
>
> -
> Ross Mellgren 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 > > 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 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 Pollak wrote:
> >
> > On Wed, Sep 23, 2009 at 10:40 AM, Naftoli Gugenheim > >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 Pollak wrote:
> > >
> > > On Wed, Sep 23, 2009 at 3:59 AM, Naftoli Gugenheim > > >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 Madsen wrote:
> > > >
> > > >
> > > > David Pollak writes:
> > > >
> > > > > I've added code (it's in review board right now) that will
> > > automatically
> > > > > farm any snippet with the "do:lazy='true'" attrib
[Lift] Re: Concurrent Web Service Requests?
On Thu, Sep 24, 2009 at 11:33 AM, Naftoli Gugenheim 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
>
> what would be the syntax to have it inserted via ajax?
>
>
> -
> Ross Mellgren 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 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 Pollak 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 Pollak 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 Madsen wrote:
> > > >
> > > >
> > > > David Pollak 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, will execute the foo snippet inline.
> > > > >
> > >
[Lift] Re: Concurrent Web Service Requests?
Can I recommend "eval" as a prefix...That then gives us eval:eager="true"
and eval:parallel="true"
On Thu, Sep 24, 2009 at 7:33 PM, Naftoli Gugenheim 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'.
>
> 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
>
> what would be the syntax to have it inserted via ajax?
>
> -
> Ross Mellgren 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 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 Pollak 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 Pollak 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 Madsen wrote:
> > > >
> > > >
> > > > David Pollak 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, will execute the foo snippet inline.
> > > > >
> > > > > 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 f
[Lift] Re: Concurrent Web Service Requests?
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
what would be the syntax to have it inserted via ajax?
-
Ross Mellgren 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 > 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 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 Pollak wrote:
>
> On Wed, Sep 23, 2009 at 10:40 AM, Naftoli Gugenheim >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 Pollak wrote:
> >
> > On Wed, Sep 23, 2009 at 3:59 AM, Naftoli Gugenheim > >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 Madsen wrote:
> > >
> > >
> > > David Pollak 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, will execute the foo snippet inline.
> > > >
> > > > 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/vie
[Lift] Re: Concurrent Web Service Requests?
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 > 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 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 Pollak wrote: > > On Wed, Sep 23, 2009 at 10:40 AM, Naftoli Gugenheim >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 Pollak wrote: > > > > On Wed, Sep 23, 2009 at 3:59 AM, Naftoli Gugenheim > >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 Madsen wrote: > > > > > > > > > David Pollak 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, will execute the foo snippet inline. > > > > > > > > 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?
On Wed, Sep 23, 2009 at 11:43 AM, Naftoli Gugenheim 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 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 Pollak wrote: > > On Wed, Sep 23, 2009 at 10:40 AM, Naftoli Gugenheim >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 Pollak wrote: > > > > On Wed, Sep 23, 2009 at 3:59 AM, Naftoli Gugenheim > >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 Madsen wrote: > > > > > > > > > David Pollak 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, will execute the foo snippet inline. > > > > > > > > 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?
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 Pollak wrote: On Wed, Sep 23, 2009 at 10:40 AM, Naftoli Gugenheim 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 Pollak wrote: > > On Wed, Sep 23, 2009 at 3:59 AM, Naftoli Gugenheim >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 Madsen wrote: > > > > > > David Pollak 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, will execute the foo snippet inline. > > > > > > 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?
On Wed, Sep 23, 2009 at 10:40 AM, Naftoli Gugenheim 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 Pollak wrote: > > On Wed, Sep 23, 2009 at 3:59 AM, Naftoli Gugenheim >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 Madsen wrote: > > > > > > David Pollak 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, will execute the foo snippet inline. > > > > > > 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?
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 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 Pollak wrote: > > On Wed, Sep 23, 2009 at 3:59 AM, Naftoli Gugenheim >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 Madsen wrote: >> >> >> David Pollak 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, will execute the foo snippet inline. >>> >>> 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?
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 Pollak wrote: On Wed, Sep 23, 2009 at 3:59 AM, Naftoli Gugenheim 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 Madsen wrote: > > > David Pollak 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, will execute the foo snippet inline. > > > > 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?
On Wed, Sep 23, 2009 at 3:59 AM, Naftoli Gugenheim 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 Madsen wrote: > > > David Pollak 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, will execute the foo snippet inline. > > > > 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?
On Tue, Sep 22, 2009 at 11:52 PM, Jeppe Nejsum Madsen wrote: > > David Pollak 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, will execute the foo snippet inline. > > > > 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?
+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 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 Madsen wrote: > David Pollak 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, will execute the foo snippet inline. > > > 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?
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 Madsen wrote: David Pollak 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, will execute the foo snippet inline. > > 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?
David Pollak 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, will execute the foo snippet inline. > > 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?
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, will execute the foo snippet inline. 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 wrote: > > On Sep 21, 5:30 pm, David Pollak > 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?
There's a difference between some experimental stuff and the robust stuff that one can build robust web apps on. I've got my finger in a fair number of the projects that you mention and I don't think (with the exception of Robey's stuff which I haven't played with a lot) I would trust my app to them. More broadly, doing premature optimization doesn't help things. The JVM, even with one thread per IO, and still serve hundreds of pages per second. Yes, if you're Twitter or LinkedIn, you have to worry about things like the number of threads your actually consuming, but for an app that's going to server 100 requests per second, even if you've got 5 threads working in parallel per concurrent request to render the page, you're not pushing any limits. On Mon, Sep 21, 2009 at 7:28 PM, espeed wrote: > > On Sep 21, 5:30 pm, David Pollak > 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 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?
On Sep 21, 5:30 pm, David Pollak 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 --~--~-~--~~~---~--~~ 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?
On Mon, Sep 21, 2009 at 3:19 PM, espeed wrote: > > On Sep 21, 4:29 pm, David Pollak > 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 -~--~~~~--~~--~--~---
[Lift] Re: Concurrent Web Service Requests?
On Sep 21, 4:29 pm, David Pollak 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?
On Mon, Sep 21, 2009 at 1:19 PM, espeed wrote: > > On Sep 21, 2:33 pm, David Pollak > 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?
On Sep 21, 2:33 pm, David Pollak 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?
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 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 -~--~~~~--~~--~--~---
