On Aug 24, 10:39 am, Viktor Klang <[email protected]> wrote:
> On Mon, Aug 24, 2009 at 8:13 AM, marius d. <[email protected]> wrote:
>
> > On Aug 24, 12:06 am, David Pollak <[email protected]>
> > wrote:
> > > On Sun, Aug 23, 2009 at 10:45 AM, marius d. <[email protected]>
> > wrote:
>
> > > > Hmmm .. I'm wondering if we can write a Scala compiler plugin that
> > > > transform functions provided to Lift's S/SHtml function etc. into a
> > > > richer FunctionX implementation that knows how to "serialize" it's
> > > > members. We could restrict the types that as LiftSerializable on top
> > > > of primitives, Calenars, SessionVar/RequestVar etc. If users need
> > > > their own classes to be LiftSerilizable they would have to implement
> > > > LiftSerializable trait.
>
> > > I think we can do it without explicit traits. I think we just need to
> > walk
> > > the graph for everything that's added to the LiftSession and see where it
> > > leads. Any graph we can walk is something that we can serialize... even
> > > without Java serialization. Any graph that ends in globals or some class
> > > that refers to native stuff (e.g., IO), then we're toast.
>
> > Totally agree. The rationale for explicit LiftSerializable would be
> > just for user defined types. Otherwise user's won't have to use it.
> > Graphs may also have be cyclic paths ... it shouldn't be too big of a
> > pain though. Furthermore if a dependency graph path leads say to an IO
> > reference maybe that's unintentional user code doesn't really use that
> > but compiler put it for whatever reason. If such cases are possible
> > and could be determined maybe we could exclude that silently from the
> > serialization operation and add a compile time warning.
>
> > I guess we need to dig more into scala compiler plugin system.
>
> 1. Isn't there a problem with references _inside_ methods that are
> impure/sideeffecting?
>
> s => { Db.myCachedInfoNotInSession foo s }
>
> Regarding member references, a simple check for "transient"
> (sca...@transient == java *transient*) to forcve people to use transient
> members for non-serializable state.
>
> But IMHO the serialization problem is a (negative?) sideeffect of Lifts rich
> model GUID=>Func approach.
> Perhpas there is a middle way, a way where we can replicate just enough to
> survive a node crash?
That's exactly it. We probably don't need everything that Java
Serialization does. Just enough to make it consistent ... the
dependency graphs that is actually used by the user's function.
>
>
>
>
>
> > > > Thoughts?
>
> > > > Br's,
> > > > Marius
>
> > > > On Aug 23, 8:30 pm, "marius d." <[email protected]> wrote:
> > > > > At a first glace Java serialization is needed because of its
> > awareness
> > > > > of the reference graph. But in the same time it does not perform
> > well.
> > > > > One way might be the byte level instrumentation that would induce
> > code
> > > > > to figure out the reference graph and know how to stream-ify it using
> > > > > a given efficient protocol. But that induces risks and it involves
> > > > > tons of work. I think would be doable though.
>
> > > > > The problem is not really the technology of propagating session
> > > > > information to other nodes. That's the easiest part, but tough one is
> > > > > figuring out the low level reference graph and serialization
> > > > > semantics. This is why JINI, JavaSpaces, JGroups, CORBA, JXTA, you
> > > > > name it, are unlikely to help solving the fundamental problem.
>
> > > > > Br's,
> > > > > Marius
>
> > > > > On Aug 23, 8:16 pm, Arthur <[email protected]> wrote:
>
> > > > > > On Sun, Aug 23, 2009 at 7:04 PM, David
>
> > > > > > Pollak<[email protected]> wrote:
> > > > > > > On Sun, Aug 23, 2009 at 4:50 AM, Kevin Wright
> > > > > > > <[email protected]> wrote:
>
> > > > > > >> I'm wondering if we can't leverage JavaSpaces to handle a lot of
> > > > this
> > > > > > >> stuff. From my experience with the technology it seems to be a
> > > > pretty good
> > > > > > >> fit for the problem.
>
> > > > > > > Two reasons:
> > > > > > > - JavaSpaces is as far as I know, GPL and we will not mix any GPL
> > > > into Lift
>
> > > > > > JavaSpaces is just the specification. There are two implementations
> > I
> > > > > > know of: BlitzJavaSpaces (BSD) and GigaSpaces (proprietary?). I
> > don't
> > > > > > have hands on experience with either.
>
> > > > > > > - It doesn't solve the issue with low-level session replication
> > which
> > > > relies
> > > > > > > on serialization of the session data for transfer to another app
> > > > server
> > > > > > > instance.
>
> > > > > > Arthur
>
> > > --
> > > Lift, the simply functional web frameworkhttp://liftweb.net
> > > Beginning Scalahttp://www.apress.com/book/view/1430219890
> > > Follow me:http://twitter.com/dpp
> > > Git some:http://github.com/dpp
>
> --
> Viktor Klang
>
> Blog: klangism.blogspot.com
> Twttr: viktorklang
>
> Lift Committer - liftweb.com
> AKKA Committer - akkasource.org
> Cassidy - github.com/viktorklang/Cassidy.git
> SoftPub founder:http://groups.google.com/group/softpub
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
