On Aug 23, 9:47 pm, Ryan Donahue <[email protected]> wrote:
> 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 tattach the lift objects tohe HttpSession to support existing
> session replication mechanisms such as Tomcat's?
There probably would as typically container's HTTPSession's are using
Java's serialization and the above would aim for a different one.
>
> 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
-~----------~----~----~----~------~----~------~--~---
