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