[04:02:37] [connected at Fri Aug 12 04:02:37 2005] [04:02:37] <> *** Looking up your hostname... [04:02:37] <> *** Checking ident [04:02:38] <> *** Found your hostname [04:03:08] <> *** No identd (auth) response [04:03:08] <> *** Your host is niven.freenode.net[fast.hub/6667], running version hyperion-1.0rc5 [04:03:08] [I have joined #peak] [09:59:47] ** vlado has joined us [10:04:06] ** vlado has left us [12:39:24] ** pje has joined us [12:39:29] ** erikrose has left IRC (Read error: 110 (Connection timed out)) [12:40:13] ** erikrose has joined us [12:57:51] ** sprout has joined us [13:21:49] pje, multiple instances of a single type of DM don't share caches or anything, do they? [13:23:31] Nope. [13:23:38] Components is components. :) [13:24:43] ** _erikrose has joined us [13:25:48] <_erikrose> I imagine the typical case is to want one DM cache per DM type per HTTP request (in a web scenario), [13:26:11] <_erikrose> so is the usual thing to offer one DM instance at a high level in the component hierarchy and have everybody Obtain it? [13:26:59] Yep. [13:27:26] And since the web hit determines transaction boundaries, that also determines the cache lifetime by default. [13:27:34] <_erikrose> Righto. [13:28:03] Zope's two big ideas: URLs==object traversal, and web hit==transaction [13:28:21] <_erikrose> That would seem to lead to needing to stick a comprehensive list of all DM's used by the project into the top-level IoC class, no? [13:28:53] Um, yeah, or to just make sure that you have stuff in the project's .ini. [13:28:54] :) [13:29:24] <_erikrose> I'm going to have to break down and learn the config framework. :-P [13:29:35] Yes, you are. :) [13:30:05] <_erikrose> Is Bulletins' .ini a good example for the DM thing? [13:30:11] Really, 90% of what a PEAK .ini file is is a lazy dialect of Python. [13:30:42] And each [section heading] possibly selects a different dialect. :) [13:31:04] I guess you could think of it as [section heading] is a function call, with lazy keyword arguments. [13:31:19] Except that keywords can repeat. [13:31:22] <_erikrose> That's part of what scared me off before: [13:31:25] And aren't limited to identifiers [13:31:31] <_erikrose> each section had a different syntax to figure out. [13:31:34] And order may be significant. :) [13:31:46] Yeah, but all the syntax functions are listed at the top of peak.ini. [13:32:02] load.settings.from = "peak.config.ini_files.do_include" [13:32:02] import.on.demand = "peak.config.ini_files.import_on_demand" [13:32:02] component.factories = "peak.config.ini_files.register_factory" [13:32:02] named.services = "peak.config.ini_files.add_services" [13:32:02] load.on.demand = "peak.config.ini_files.load_on_demand" [13:32:03] xml.attributes.for.* = "peak.config.ini_files.define_xml_attributes" [13:32:03] <_erikrose> Yep, I read peak.ini. [13:32:05] xml.elements.for.* = "peak.config.ini_files.define_xml_elements" [13:32:40] <_erikrose> Oh, waitaminute. [13:32:44] Anyway, I guess what it amounts to is that PEAK .ini files are Python macros. :) [13:33:08] I never actually thought of it that way before. [13:33:34] <_erikrose> Even if you define your DM-to-model-object mappings in the config file, don't you still need a big list of Obtain's in the top-level IoC class? [13:33:53] <_erikrose> How do you not RepeatYourself there? [13:34:21] <_erikrose> Well, I guess it's strictly not RepeatingYourself; [13:34:34] <_erikrose> the config file defines the mappings, and the IoC listing defines the scoping. [13:34:43] Um, no. [13:34:51] Components that need the DM just Obtain it. [13:35:08] the ServiceArea is what defines scope for "global" instances. [13:35:15] <_erikrose> Ah, that's what I wanted to know. [13:35:23] By default, the ServiceArea is your configuration root. [13:35:23] <_erikrose> What's a ServiceArea and how much do they cost? ;-) [13:35:31] <_erikrose> Wunderbar. Perfect. Thanks. [13:35:47] However, commands like peak runIni create a new service area with the given config and run things under it. [13:36:05] You can also explicitly create a config.ServiceArea instance and use it as a parent. [13:36:39] Anything registered via [Component Factories] will create an instance in the ServiceArea if your Obtain falls through that far. [13:36:58] i.e., if there's nothing more "local" than the service area, then you get an on-demand "global" instance at the service level. [13:37:04] It's not really global, just per-service area. [13:37:21] <_erikrose> Utterly perfect. [13:37:30] <_erikrose> I imagine that's what's desired for almost all cases. [13:37:39] Also note this means that if you have interdependent services (like a DM using a DB and a transaction service), then anything defined at the service area is going to get another one at the service area. [13:37:44] <_erikrose> So in practice, one doesn't Make() a lot of DM's in code, eh? [13:38:00] Nope, you should never have to if you're using .ini's to set up service areas. [13:38:51] <_erikrose> What do you mean by "anything defined at the service area is going to get another one at the service area"? [13:39:23] Meaning that if you have a DM in the service area, it's going to use the service area to find the transaction service. [13:39:37] It's not going to use a transaction service local to where you asked for it. [13:39:52] i.e., let's say you have a component w/its own txn svc, that Obtain()s a DM. [13:40:05] But there's no local DM, so you get the service area one instead [13:40:35] That means the DM you get, is using the global txn svc [13:40:56] <_erikrose> That all sounds like it would be desirable, no? [13:41:07] Depends on what you're doing. [13:41:07] <_erikrose> My txn belongs only to my configroot right now, as that's the default. [13:41:24] ** erikrose has left IRC (Read error: 110 (Connection timed out)) [13:41:28] Yeah, I'm just pointing out it applies to any service you use. Most applications really only need one service area. [13:42:06] I'm just saying that this applies to anything you Make() on a more local level, if you also Obtain() something that you want to have use what you Make(). [13:42:23] <_erikrose> So you're saying that if a component lookup falls all the way through to a config file, consequent lookups start at the config file? [13:42:58] <_erikrose> consequent meaning dependent, like DM-needs-a-DB-connection [13:59:52] yes [14:00:44] <_erikrose> Boffo. I'm reading the bulletins source now for an example of this stuff. I may have more obnoxious questions for you soon. [14:33:09] _erikrose is now known as erikrose [16:23:11] ** pje_ has joined us [16:32:50] ** pje__ has joined us [16:38:40] ** pje has left IRC (Read error: 113 (No route to host)) [16:40:29] ** pje has joined us [16:50:51] ** pje_ has left IRC (Read error: 110 (Connection timed out)) [16:54:14] ** pje__ has left IRC (Read error: 113 (No route to host)) [18:28:55] ** pje_ has joined us [18:28:56] ** pje has left IRC (Read error: 104 (Connection reset by peer)) [18:43:59] ** pje__ has joined us [18:47:32] ** pje_ has left IRC (Read error: 104 (Connection reset by peer)) [19:45:22] ** pje__ has left IRC ("Client exiting") [19:56:03] ** uzbit has joined us [19:56:10] ** uzbit has left us [21:19:27] ** sprout has left IRC ("Snak 5.0 IRC For Mac - http://www.snak.com")