David, Can one leave proxies in place for things that are not actually serializable?
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 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 > > > > -- L.G. Meredith Managing Partner Biosimilarity LLC 1219 NW 83rd St Seattle, WA 98117 +1 206.650.3740 http://biosimilarity.blogspot.com --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
