[Catalyst] DNS as a Catalyst Model

[Jonathan Swartz]

Sorry, wrong subject...reposting...

On Jun 7, 2007, at 3:53 AM, Jonathan Swartz wrote:

> mia wrote:
> >Matt S Trout wrote:
> >> On Wed, Jun 06, 2007 at 02:18:33PM -0700, mla wrote:
> >>> Matt S Trout wrote:
> >>>> On Wed, Jun 06, 2007 at 12:29:12PM -0700, mla wrote:
> >>>>> Is it not possible to offer the current Catalyst instance  
> through
> >>>>> a class method? Something analogous to Apache->request,  
> rather than
> >>>>> having to do the whole ACCEPT_CONTEXT prototype object thing?
> >>>> Not without limiting ourselves in terms of planned future  
> features. Jifty
> >>>> does this because they're explicitly one app per process. We  
> aren't.
> >>> When you say "per process," you mean operating system process?
> >>> You're talking about threading issues?
> >>
> >> Threading, forking, and OS-level COW.
> >
> >Forking and COW would apply just as much to instances though.
> >
> >Assuming I'm not using threads, how would I hurt myself by
> >subclassing Catalyst and supplying a MyApp->context that returns
> >the current catalyst context?
>
> Yes, I'd like to know more about this too please. Mason has a  
> similar construct - HTML::Mason::Request->instance() - and it works  
> fine with Mason subrequests or recursive calls to an entirely  
> different Mason interpreter. It just returns the value of a  
> dynamically scoped variable that is set at the beginning of a Mason  
> request.
>
> I dislike the fact that anything that needs to access the current  
> context object has to be written as a component, and thus have a  
> completely different calling signature than just a plain extension.
>
> Jon
>