I understand your thoughts David ... but I'm not convinced that Java serialization is the way to go. A more efficient serialization of the dependency graph sounds more appropriate but also quite complex.
Br's, Marius On Aug 25, 12:42 am, David Pollak <[email protected]> wrote: > On Mon, Aug 24, 2009 at 12:58 PM, Meredith Gregory <[email protected] > > > wrote: > > David, > > > Can one leave proxies in place for things that are not actually > > serializable? > > Anything that's marked serializable should be... and it's up to the thing > that marks itself as serialiable to create a proxy. Things that are not > marked as serializable may or may not be... the issue is what kind of > instance variables they have to determine if they could be serialized. > > > > > > > Best wishes, > > > --greg > > > On Mon, Aug 24, 2009 at 12:55 PM, David Pollak < > > [email protected]> wrote: > > >> On Mon, Aug 24, 2009 at 12:36 PM, marius d. <[email protected]>wrote: > > >>> Just a FYI. I briefly talked with Martin and he said this idea is > >>> possible but quite tricky. Stephane Micheloud did something similar > >>> and he may share some of his work. I'm waiting some feedback from him. > > >> I think we can do it at runtime in development mode. This is just for > >> data gathering, not for actual implementation. We just need to calculate > >> whether a given class is serializable once... so we don't have to worry > >> about cyclic graphs or anything else... just... are the "slots" (instance > >> variables) for each class serializable. > > >>> Br's, > >>> Marius > > >>> On Aug 24, 10:46 am, "marius d." <[email protected]> wrote: > >>> > 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 aScalacompilerpluginthat > >>> > > > > > 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 intoscalacompilerpluginsystem. > > >>> > > 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 > >>> > > > > BeginningScalahttp://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 > > >> -- > >> 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 > > > -- > > L.G. Meredith > > Managing Partner > > Biosimilarity LLC > > 1219 NW 83rd St > > Seattle, WA 98117 > > > +1 206.650.3740 > > >http://biosimilarity.blogspot.com > > -- > 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 --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
