Marius, this sound like a very good idea. This would allow the app developer to decide whether to spend the extra time thinking about serialization/session replication. If you don't need it, then you don't use the compiler plugin and just continue building lift apps as you have been. If you do need it, then you use the plugin and you'll have compiler errors or warnings telling you where you need to make use of LiftSerializable.
If the serializing problems are handled, would there be any reasons not to attach the lift objects to the HttpSession to support existing session replication mechanisms such as Tomcat's? On Aug 23, 1:45 pm, "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. > > 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 --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
