Lift has no dependency on it's various optional persistence layers. I don't see 
any advantage in terms of data layer to not using lift.
But I'd like to question your reason for using GAE. I started a project in Lift 
for GAE which I soon switched away from GAE. As far as I remember there is no 
special integration with Google Docs. There is built in integration with your 
Google account and there is an API to send mail with Gmail, but the Google Docs 
API is an ordinary Java library wrapping an ordinary XML API that can be used 
with zero dependency on GAE.
If there's another reason would you like to share it?
Also note stax.net, which I believe has free Java hosting, and they have a 
built in project type for lift.

-------------------------------------
__kaveh__<[email protected]> wrote:

@David Pollak Thanks for your time and answering me!

I am evaluating Cloud technologies for a social application - without
heavy real-time interaction - GAE appealed to me for easy integration
and interaction with other utilities in Google (like Google Docs which
is another candidate for us for handling documents). We are basically
a .NET team; and for reducing out hosting and especially database
cost; we are evaluating other technologies. On JVM - which can be used
on GAE (at least to some extend) - I have looked into Clojure and
Scala.

Clojure is an elegant language "but" it is a Lisp and it is dynamic -
and that "but" is very real and pragmatic to me. Scala on the other
hand, is almost simply what we need - that's the best I can tell.
Again "but" not because of it's power in concurrent computing, rather
because of it's EXPRESSIVENESS and EXTENDABILITY and providing rich
options for tailoring data structures in a static language - traits
are a real joy to use.

So there can be a face of Scala without it's concurrent features that
helps to just step in "functional programming" land; concurrency will
soon enough comes onto one's pass.

Clojure have not a mature and even 1.0 web framework; Scala has Lift -
which I have not even enough sight to grasp it's elegance, whole - and
it uses it's model of concurrency. So for cases like many little web
applications that concurrency is not an issue or for technologies like
GAE; we should simply fall back to Java?

Thanks

@Naftoli Gugenheim I am aware that Lifts runs on GAE ... but without a
data layer?!!!

On Jan 14, 7:38 am, David Pollak <[email protected]>
wrote:
> On Wed, Jan 13, 2010 at 3:13 PM, __kaveh__ <[email protected]>wrote:
>
> > Agreed; things like Comet Style request processing; yet Lift model for
> > separating concerns and it's powerful template system can really makes
> > a complete web application ecosystem on GAE.
>
> The all of the "standard" parts of Lift work on GAE except Comet and Mapper.
>  Comet doesn't work because of the ban in GAE of creating threads (Actors)
> and Mapper doesn't work because there's no JDBC source on GAE.
>
> With that being said, I personally think GAE is the worst of all possible
> worlds.  GAE has a severely limited run-time (the idea of not being able to
> have asynchronous messages is a huge limitation).  BigTable is good for a
> limited number of things, but even the most trivial apps (e.g., yet another
> Twitter Clone) is going to require a relational database or some other model
> beyond what BigTable offers.
>
> GAE nominally scales well, but if you're moving to Twitter-like traffic,
> you're not going to want to be tied to Google's infrastructure... it's just
> too scaring from a business perspective.
>
> For $10/mo, you can rent a slice at SliceHost or prgmr.com that will run a
> nice app and allow it to scale to hundreds or maybe thousands of users.
>
> So, if you have an actual need for Lift on GAE for an actual production site
> and Lift is not offering a particular something you need, please tell us
> about it and we'll see about scheduling a fix.
>
> Thanks,
>
> David
>
>
>
>
>
> > On Jan 14, 1:51 am, Randinn <[email protected]> wrote:
> > > The problem as far as I know is the GAE sandboxing inhibits most of
> > > what makes lift, lift.
>
> > > On Jan 14, 8:56 am, __kaveh__ <[email protected]> wrote:
>
> > > > Introduction: I apologize in advanced for I am naive about Scala, Lift
> > > > and elegant design decisions in Lift. I am a C#/ASP.NET/Windows
> > > > Application developer. I played with Scala and it was the C# I was
> > > > looking for! My job is on .NET platform. But for enjoying something
> > > > (and maybe put into real use later) Scala and Lift are really nice
> > > > choices (IMHO).
>
> > > > Could there be an official GAE (Google App Engine) version of Lift?
>
> > > > It appears that - for some reason I can not figure out; one of them
> > > > for sure is elegance - Lift and Scala are attracting to those who want
> > > > to use GAE/J. This can be a winning/dominated playground for both of
> > > > them (even if we put aside concurrency features in GRE) for those who
> > > > want to use GRE/J.
>
> > > > Regards
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Lift" group.
> > To post to this group, send email to [email protected].
> > To unsubscribe from this group, send email to
> > [email protected]<liftweb%[email protected]>
> > .
> > For more options, visit this group at
> >http://groups.google.com/group/liftweb?hl=en.
>
> --
> Lift, the simply functional web frameworkhttp://liftweb.net
> Beginning Scalahttp://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 [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.


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


Reply via email to