Re: Pooling, costs, etc.

> hi,
> 
> On Thu, 02 Jan 2003 15:37:02 +0000, [email protected] said:
> 
> > single-server and clustered behavior is the same ... just as a backup service 
> > in a cluster receives only copies of persistent properties, so will a single-
> > server; it ensures that the copy is the same for both.
> 
> yeah, that's not a bad thing...
> 
> > Given that the vast majority of persistant properties will be String, Date, 
> > boolean, int, etc. (that is, easily identifyable immutables), the cost is 
> > actually not so great. 
> 
> but it's still inconvenient to clear stuff out in detach(), with
> components it's even more so (implement interface, etc).

Mind Bridge is looking into taking care of that inconvienience by creating,
dynamically, a subclass that implements the necessary accessors, instance
variables, and other methods.  Just like magic!

BTW ... I'm jealous, but also swamped.  Letting someone else perform this
kind of major surgery on Tapestry is a real test of my dedication to a community 
process ... (sniff) baby is growing up now (sniff).



> 
> > I'll noodle on the idea of a "peer" that stores persistant state.  I'm not 
> > immediately seeing a way to do it that doesn't break most existing 
> > applications, and I'm concerned that creating new pages will involve a
> > page spec, template and TWO classes (one for logic, one for data storage). 
> > Seems less natural to me.
> 
> the peer i was trying to describe is not for storing the persistent
> properties, that could still be done with fireObservedChange().. it's for
> the expensive stuff that made pooling neccessary to begin with - you
> probably know better what these are, but i guess the component
> specification, bindings, assets - which is usually not a whole lot
> outside of the framework, so one would very rarely need to subclass the
> Peer (like, never?).
> 
> as far as refactoring existing code goes, i think you should be able to
> keep all but a few methods in the IComponent hierarchy, but make the
> implementations delegate to the peer.. eg. getBinding(...) { return
> peer.getBinding(...) }  - this way existing client code doesnt have to be
> changed much, other than removing the detach that's no longer needed...
> 
> best regards,
>    viktor
> -- 
>   
>   [email protected]
> 
> -- 
> http://fastmail.fm - Faster than the air-speed velocity of an
>                       unladen european swallow
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Tapestry-contrib mailing list
> Tapestry-contrib-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/tapestry-contrib


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf