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