| srichter | that's a shame | 00:00 | 
|---|---|---|
| projekt01 | You have URL's like http://localhost:8080/folder/contents.html/++help++contexthelp.html | 00:00 | 
| projekt01 | This means we get the context at http://localhost:8080/++help++contexthelp.html | 00:00 | 
| projekt01 | Adapting the folder/contes.html view as the context | 00:01 | 
| srichter | but that does not matter | 00:01 | 
| srichter | because the OnlineHelp class is a ContainmentRoot | 00:01 | 
| srichter | that means everything is relative to ++help | 00:01 | 
| srichter | ++help++ | 00:01 | 
| projekt01 | Yes, but... | 00:02 | 
| projekt01 | You accessing the contectual help on the URL | 00:02 | 
| projekt01 | http://localhost:8080/folder/contents.html/++help++contexthelp.html | 00:03 | 
| srichter | mmh, I don't understand what the problem is | 00:03 | 
| srichter | ok, so what? | 00:03 | 
| projekt01 | This points to the topic say, ++help++/first topic | 00:03 | 
| projekt01 | The child of first topic is xxx | 00:03 | 
| projekt01 | If you access it via the contextual topic view the URL doesn't it to the child | 00:04 | 
| projekt01 | One more example: | 00:04 | 
| projekt01 | The URL of the contextual topic is: | 00:04 | 
| projekt01 | http://localhost:8080/folder/contents.html/++help++contexthelp.html | 00:05 | 
| projekt01 | The URL of the child is: | 00:05 | 
| projekt01 | http://localhost:8080/++help++/child/index.html | 00:05 | 
| projekt01 | The cookie tree can't hanlde this jkind of URL | 00:06 | 
| srichter | oh, I see | 00:06 | 
| srichter | so really, only the first level is a problem | 00:06 | 
| srichter | it would be better if the first URL were: ++help++/contexthelp.html | 00:06 | 
| projekt01 | No you can access contextual topics on every context | 00:06 | 
| srichter | oooh, I see | 00:07 | 
| srichter | so contexthelp.html should forward you to something like http://localhost:8080/++help++/topic | 00:07 | 
| projekt01 | Contexthelp.html is a view adapting the context, The context is something like localhost:8080/site/folder | 00:08 | 
| projekt01 | ++help++ makes the adaption | 00:09 | 
| projekt01 | For the contextual help view | 00:09 | 
| srichter | J1m: what do I have to do again, so that I can use "..." as a wildcard in doctests? | 00:19 | 
| srichter | J1m: nevermind | 00:20 | 
| *** _projekt01 has joined #zope3-dev | 00:29 | |
| *** projekt01 has quit IRC | 00:29 | |
| *** tvon|desk has joined #zope3-dev | 00:52 | |
| benji_york_zope | srichter, I'm getting a functional test failure... | 00:52 | 
| benji_york_zope | ZopeXMLConfigurationError: File "/home/benji/test/src/zope3/src/zope/app/apidoc/bookmodule/book.zcml", line 5.2 | 00:52 | 
| benji_york_zope | ConfigurationError: ('Unknown directive', u'http://namespaces.zope.org/apidoc', u'bookchapter') | 00:52 | 
| srichter | ok, done | 00:54 | 
| benji_york_zope | thanks | 00:54 | 
| srichter | however, the bookmoduel depends on the onlinehelp | 00:54 | 
| srichter | which Jim just mentioned you don't have | 00:54 | 
| benji_york_zope | same error | 00:56 | 
| srichter | do you have onlinehelp installed? | 00:56 | 
| benji_york_zope | I don't think so. | 00:57 | 
| srichter | right, can you install it in your installation? | 00:57 | 
| srichter | otherwise you have to comemnts out the bookmodule | 00:57 | 
| benji_york_zope | Is the bookmodule part of the standard instance skeleton? | 00:57 | 
| GaryPoster | what configure.zcml imports the bookmodule? | 00:57 | 
| GaryPoster | (hi stephan ;-) ) | 00:58 | 
| srichter | apidoc/configure.zcml | 00:58 | 
| srichter | GaryPoster: hi | 00:58 | 
| srichter | also, you need to comment out the meta configure stuff for the bookmodule in package-includes/apidoc-meta.zcml | 00:58 | 
| J1m | we'll just load onlinehelp for now | 01:01 | 
| srichter | ok | 01:01 | 
| J1m | so apidoc depends on onlinehelp. | 01:03 | 
| J1m | That's fair enough. | 01:03 | 
| J1m | As long as they are both optional. | 01:04 | 
| J1m | We want apidoc during development, so we'll load onlinehelp then as well. | 01:04 | 
| GaryPoster | for now, I tried <include package="zope.app.onlinehelp"/> and I still got ZopeXMLConfigurationError: File "/Users/gary/jicpac/src/Zope3-trunk/src/zope/app/onlinehelp/help/configure.zcml", line 8.2 | 01:04 | 
| GaryPoster | ConfigurationError: ('Unknown directive', u'http://namespaces.zope.org/help', u'register') | 01:04 | 
| J1m | You have to load the meta.zcml too. | 01:04 | 
| GaryPoster | eh, I guess I need the meta first. | 01:04 | 
| GaryPoster | right | 01:05 | 
| srichter | ok, gotta go | 01:07 | 
| srichter | send me a mail, if you have troubles | 01:08 | 
| *** srichter has quit IRC | 01:08 | |
| *** benji_york_zope has quit IRC | 01:18 | |
| *** GaryPoster has quit IRC | 01:20 | |
| * tvon|desk wonders why the jscript menu is busted in the CSS skin | 01:30 | |
| tvon|desk | nm | 01:33 | 
| *** srichter has joined #zope3-dev | 01:38 | |
| *** ChanServ sets mode: +o srichter | 01:39 | |
| *** mexiKON has joined #zope3-dev | 01:43 | |
| *** philiZZZ has quit IRC | 02:00 | |
| _projekt01 | Tvon|desk, do you mean the CSS skin I check in before? | 02:06 | 
| tvon|desk | _projekt01: yeah, its fine... didn't realize that the nav menu needed some css to not die | 02:07 | 
| _projekt01 | Yup, I hope we can define the styles from scratch in the next couple days. | 02:08 | 
| tvon|desk | I might toss something to the list tonight.. | 02:09 | 
| tvon|desk | if I dont go see a bad movie | 02:09 | 
| *** J1m has quit IRC | 02:28 | |
| *** hazmat has joined #zope3-dev | 03:06 | |
| *** hazmat has quit IRC | 03:53 | |
| tvon|desk | Is anyone really attached to the javascript menus? | 04:14 | 
| srichter | not me, but how else do you want to do sub-menues later? | 04:15 | 
| tvon|desk | without reloading the whole page? dunno really... | 04:17 | 
| *** niemeyer has quit IRC | 04:17 | |
| srichter | so it's a usability issue | 04:17 | 
| srichter | I have seen JS menus that work well in Konqui as well ;-) | 04:18 | 
| srichter | that's all I care about | 04:18 | 
| tvon|desk | the current one is busted on konqi, right? | 04:19 | 
| tvon|desk | suppose I should just install it... | 04:20 | 
| srichter | oh, you mean the tree | 04:20 | 
| srichter | we really should use static tree for the tree | 04:20 | 
| srichter | Konqui does not handle the current one | 04:20 | 
| _projekt01 | Let's develope a own js tree implementation with fits in (all) browser | 04:21 | 
| tvon|desk | srichter: what tree were you talking about? | 04:22 | 
| srichter | on the left side | 04:22 | 
| tvon|desk | _projekt01: there are lots of trees out there, likely easier to find one that fits whatever licensing requirements we have | 04:22 | 
| srichter | we should not go there | 04:22 | 
| tvon|desk | third party code? | 04:23 | 
| srichter | yes | 04:23 | 
| _projekt01 | I now many of them, but they all doesn't fit for my wishes. | 04:23 | 
| _projekt01 | Support for opera, konquerror, support reload via http request in the background, support drag and drop for nodes etc | 04:24 | 
| srichter | if the developer is not willing to check in the code under ZPL in our repository, then its a no go | 04:24 | 
| _projekt01 | And you find many trees which are build with javascript methods like tree = new Tree(); tree.addItem(level, node) | 04:25 | 
| *** `anthony has quit IRC | 07:03 | |
| *** `anthony has joined #zope3-dev | 07:32 | |
| *** apauley|away is now known as apauley | 08:10 | |
| *** srichter has quit IRC | 08:27 | |
| *** zagy has joined #zope3-dev | 08:39 | |
| *** stub has joined #zope3-dev | 08:56 | |
| zagy | moin | 09:02 | 
| *** Theuni has joined #zope3-dev | 09:28 | |
| *** d2m has quit IRC | 09:51 | |
| *** d2m has joined #zope3-dev | 09:55 | |
| *** `anthony has quit IRC | 09:56 | |
| *** hdima has joined #zope3-dev | 10:53 | |
| *** mgedmin has joined #zope3-dev | 11:07 | |
| *** gintas has joined #zope3-dev | 11:12 | |
| *** J1m has joined #zope3-dev | 11:15 | |
| *** MalcolmC has joined #zope3-dev | 11:16 | |
| *** bskahan has quit IRC | 11:43 | |
| *** zug has joined #zope3-dev | 11:57 | |
| *** rejj has quit IRC | 11:57 | |
| *** zug is now known as rejj | 11:57 | |
| *** AJC has quit IRC | 11:58 | |
| *** apauley has quit IRC | 12:33 | |
| *** gintas has quit IRC | 13:04 | |
| *** gintas has joined #zope3-dev | 13:06 | |
| *** alga has joined #zope3-dev | 13:13 | |
| *** zug has joined #zope3-dev | 13:24 | |
| *** rejj has quit IRC | 13:24 | |
| *** zug is now known as rejj | 13:24 | |
| *** srichter has joined #zope3-dev | 13:35 | |
| *** ChanServ sets mode: +o srichter | 13:35 | |
| *** Theuni has quit IRC | 13:36 | |
| *** niemeyer has joined #zope3-dev | 14:10 | |
| *** J1m has quit IRC | 14:18 | |
| *** rejj has quit IRC | 14:19 | |
| *** `anthony has joined #zope3-dev | 15:03 | |
| *** tarek has joined #zope3-dev | 15:11 | |
| *** rejj has joined #zope3-dev | 15:16 | |
| *** stub has quit IRC | 15:20 | |
| *** stub has joined #zope3-dev | 15:26 | |
| *** regebro has quit IRC | 15:29 | |
| *** mgedmin has quit IRC | 16:12 | |
| *** vlado has joined #zope3-dev | 16:18 | |
| *** gintas has quit IRC | 16:22 | |
| *** AJC has joined #zope3-dev | 16:27 | |
| tarek | srichter: hello | 16:28 | 
| srichter | tarek: hello | 16:29 | 
| tarek | about my mail on zope3-dev, maybe i can explain it here if you have a minute ? | 16:29 | 
| srichter | sure | 16:29 | 
| srichter | (thought I am not the most familiar guy with mailers) | 16:30 | 
| tarek | ok, so what i have understood of the mail queuing thing | 16:30 | 
| srichter | mmh, marius is not here today; he wrote the thing | 16:30 | 
| tarek | oh ok do you want me to wait for him instead ? | 16:30 | 
| srichter | I think so | 16:31 | 
| tarek | Ok | 16:31 | 
| srichter | I think I understnad your problem; I am just not qualified to answer | 16:31 | 
| tarek | ok | 16:31 | 
| *** J1m has joined #zope3-dev | 16:32 | |
| srichter | tarek: how many SMTP servers are you dealing with? | 16:33 | 
| srichter | tarek: this seems a very unusual scenario | 16:33 | 
| tarek | i am making a webmail that let each user specify his or her smtp | 16:33 | 
| tarek | at this time i have a simple call to a regular webmail | 16:34 | 
| tarek | at this time i have a simple call to a regular sendmail | 16:34 | 
| tarek | but i wanted to used the threaded queue | 16:34 | 
| tarek | because it rocks | 16:34 | 
| tarek | no i need to figure out how to be able to give smtp infos on the fly | 16:35 | 
| tarek | and in *one* queue | 16:35 | 
| tarek | i think it is not possible as ti is right now | 16:35 | 
| srichter | so here is what I would do: write your own IMailer interface that extends the current one and overrides this particular method | 16:36 | 
| srichter | this way you do not have to mess with the existing implementation | 16:36 | 
| tarek | yes indeed, that what i wanted to do, but i was not sure | 16:36 | 
| tarek | i wnated to implement IMailQueueProcessor with my own IMailer interface for the mailer object | 16:37 | 
| tarek | thanks for the tip | 16:38 | 
| srichter | yep | 16:39 | 
| *** hdima has quit IRC | 16:43 | |
| mexiKON | srichter, you got any idea why benji york committed to a tag?? | 16:45 | 
| mexiKON | nevermind, i see he committed to the trunk as well | 16:45 | 
| srichter | they work on the tag until they can receover from my merge | 16:46 | 
| mexiKON | ic | 16:47 | 
| mexiKON | i figured something like this | 16:47 | 
| mexiKON | i was just stumbled by the fact that he was committing to a tag | 16:47 | 
| srichter | yeah, I think he was not even thinking about it :-) | 16:47 | 
| J1m | it was an accident | 16:52 | 
| J1m | and a test to see if mexiKON was paying attention. | 16:52 | 
| mexiKON | :) | 16:52 | 
| srichter | the checkin police strikes again! :-) | 16:53 | 
| mexiKON | i actually am still reading checkins but most of the time i don't have the time to "strike" when i see something | 16:54 | 
| mexiKON | but srichter is covering me well :) | 16:54 | 
| *** vlado has quit IRC | 17:07 | |
| *** vlado has joined #zope3-dev | 17:09 | |
| *** GaryPoster has joined #zope3-dev | 17:26 | |
| *** mgedmin has joined #zope3-dev | 17:49 | |
| *** __gotcha has quit IRC | 18:20 | |
| *** __gotcha has joined #zope3-dev | 18:21 | |
| *** tvon|desk has quit IRC | 18:33 | |
| *** bskahan has joined #zope3-dev | 18:51 | |
| *** AJC has quit IRC | 19:31 | |
| *** tvon|desk has joined #zope3-dev | 19:33 | |
| *** __gotcha has quit IRC | 19:36 | |
| mexiKON | srichter, btw, in favour of making a 3.1 release easier, i think the new i18n message impl shouldn't be in it | 19:43 | 
| mexiKON | when i was still working on it i ran into some problems that i need to further discuss | 19:44 | 
| *** MalcolmC has quit IRC | 19:44 | |
| mexiKON | plus, nothing in the trunk uses the new implementation anyways | 19:44 | 
| mexiKON | so, it's currently just sitting there on its own | 19:45 | 
| *** benji_york has joined #zope3-dev | 19:48 | |
| srichter | mexiKON: wasn't the recent work on it solving the last problem? | 20:12 | 
| mexiKON | i never quite finished it | 20:15 | 
| srichter | what is missing? | 20:19 | 
| mexiKON | nothing's missing | 20:20 | 
| mexiKON | it's the way you work with messages | 20:20 | 
| mexiKON | creating new ones | 20:20 | 
| mexiKON | etc | 20:20 | 
| mexiKON | since they are immutable | 20:20 | 
| mexiKON | there were some unresolved issues | 20:20 | 
| srichter | ok | 20:20 | 
| J1m | srichter, is there a simplified api for registering utilities? | 20:33 | 
| srichter | in zope.app.testing.ztapi there is | 20:33 | 
| J1m | Hm | 20:33 | 
| srichter | really, much of ztapi needs to go somewhere else | 20:33 | 
| srichter | its generally useful | 20:33 | 
| J1m | agreed | 20:33 | 
| J1m | some if it should be deprecated. | 20:34 | 
| srichter | yeah, I noticed a lot of overlap between placefulsetup, ztapi, ... | 20:34 | 
| srichter | I did not feel qualified to do so, though | 20:34 | 
| J1m | I want to get rid of placefulsetup someday. | 20:35 | 
| J1m | I never use it myself any more. | 20:35 | 
| srichter | it has useful stuff in it | 20:35 | 
| srichter | like setUpAnnotation | 20:35 | 
| srichter | or setUpTraversal | 20:35 | 
| srichter | I really like these shortcuts | 20:35 | 
| J1m | srichter, is there a simplified api for registering *local* utilities? | 20:35 | 
| srichter | I always found it annoying to do that myself | 20:35 | 
| srichter | I think it is in placefullsetup | 20:36 | 
| J1m | :( | 20:36 | 
| srichter | nope, it is not | 20:36 | 
| srichter | let me search further | 20:36 | 
| srichter | oh, it is in setup.py | 20:36 | 
| srichter | that's where all the other useful functions are I just mentioned.... | 20:37 | 
| srichter | def addUtility(sitemanager, name, iface, utility, suffix='') | 20:37 | 
| srichter | I think having a fully-colored zope.app.component API like zope.component would be nice | 20:38 | 
| srichter | I started this already | 20:38 | 
| mgedmin | srichter, what do you mean by "fully-colored"? | 20:41 | 
| srichter | mgedmin: an API that provides all the tools you would want | 20:42 | 
| srichter | like zope.component does now | 20:42 | 
| *** vlado has quit IRC | 20:42 | |
| srichter | registerLocalUtility(), registerLocalAdapter(), ... | 20:43 | 
| srichter | mgedmin: so you are going to implement zcml:condition this weekend? :-) | 20:44 | 
| mgedmin | srichter, yes | 20:44 | 
| srichter | that's so cool | 20:44 | 
| mgedmin | implementation hints are welcome, of course ;) | 20:45 | 
| srichter | mmh, I was thinking about it and I was really at a loss | 20:45 | 
| mgedmin | I suppose I'll take a look at the old zcml:condition that was removed | 20:45 | 
| srichter | I guess you would have to hard code the handler somehow | 20:45 | 
| mgedmin | find out the places that need to be modified | 20:45 | 
| srichter | was the old code available as an attribute on any directive (J1m)? | 20:46 | 
| J1m | are you talking about zcml:condition? | 20:50 | 
| srichter | yeah | 20:51 | 
| J1m | zcml:condition can apply to any directive. | 20:51 | 
| srichter | and that was already implemented? | 20:51 | 
| srichter | cool | 20:51 | 
| J1m | mgedmin, I hope you'll start with the work that Fred did. | 20:51 | 
| J1m | That's why I have the revision number in my rfc last night. | 20:52 | 
| J1m | That's why I gave the revision number in my rfc last night. | 20:52 | 
| mgedmin | J1m, I was planning to start by reading that checkin you mentioned yesterday | 20:52 | 
| J1m | There are two parts: | 20:52 | 
| J1m | 1. controllng zcml | 20:52 | 
| J1m | 2. evaluating expressions | 20:53 | 
| J1m | You should be able to reuse 1. | 20:53 | 
| * mgedmin was just bitten (indirectly) by http://collector.zope.org/Zope3-dev/360 | 20:53 | |
| J1m | You'll have to redo 2. | 20:53 | 
| J1m | should be easy to fix | 20:53 | 
| srichter | oh, this seems very easy | 20:54 | 
| srichter | the implementation was slick | 20:54 | 
| mgedmin | by changing MultiSelectWidget to always return set.Set objects? | 20:54 | 
| J1m | mgedmin, no, by creating flavors appropriate for the field type. | 20:54 | 
| J1m | They can probably subclass that one and let it still do most of the heavy lifting. | 20:55 | 
| * mgedmin greps throught configure.zcmls | 20:56 | |
| mgedmin | MultiSelectWidget is only registered for (ISet, IVocabularyTokenized) | 20:57 | 
| mgedmin | so the field type is always ISet -- or do I misunderstand what you mean by "field type"? | 20:57 | 
| J1m | In that case, the field type is always ISet. | 20:57 | 
| J1m | Perhaps this thing should also be registered for IList (with unique) and ITuple (with unique), | 20:58 | 
| J1m | Does this thing let you control ordering? | 20:58 | 
| mgedmin | no, but there's an OrderedMultiSelectWidget that inherits from MultiSelectWidget | 20:59 | 
| J1m | ah | 20:59 | 
| mgedmin | err, no it doesn't | 20:59 | 
| mgedmin | class OrderedMultiSelectWidget(ItemsMultiEditWidgetBase): | 20:59 | 
| mgedmin | so it seems to me that the simplest fix would be | 20:59 | 
| mgedmin | def _toFieldValue(self): | 20:59 | 
| Workblia | mgedmin, i tried fixing it, yet it breaks some tests | 21:00 | 
| mgedmin | return sets.Set(ItemsMultiEditWidgetBase._toFieldValue(input)) | 21:00 | 
| Workblia | oh you mean one level higher | 21:01 | 
| mgedmin | Workblia, two levels lower | 21:01 | 
| mgedmin | Workblia, you changed MultiDataHelper._toFieldValue directly, which is used for lists as well | 21:01 | 
| Workblia | i see | 21:02 | 
| Workblia | will you do it or should i try fixing it ? | 21:02 | 
| mgedmin | I'm working on something else at the moment | 21:03 | 
| Workblia | i am working on widgets then | 21:03 | 
| Workblia | MultiCheckBoxWidget is it Set or List based ? | 21:13 | 
| Workblia | and how to check ? | 21:13 | 
| J1m | srichter, the bootstrap code is in poor shape. | 21:20 | 
| J1m | It's rather brittle. | 21:20 | 
| srichter | I know | 21:20 | 
| srichter | it is disgusting | 21:20 | 
| Workblia | can i draw an ascii pentagram in widget code to protect me ? | 21:22 | 
| * mgedmin was wondering the other day how he could hook into bootstrap code and create the root folder differently | 21:23 | |
| * mgedmin was also wondering whether he could use zcml overrides to replace an event handler | 21:23 | |
| J1m | You can't currently override subscribers. | 21:24 | 
| SteveA | i totally removed the zcml that references bootstrap code for launchpad | 21:25 | 
| SteveA | seeing as we're not depending on zodb for root objects | 21:26 | 
| mgedmin | and I can't control the order of subscribers either | 21:27 | 
| SteveA | i think the bootstrap code should be run on creating an instance, and by the upgrade script on upgrading an instance. not automatically at startup. | 21:27 | 
| SteveA | mgedmin: i had an idea once about each bootstrap subscriber sending an "IThatBootstrapTaskFinised" event | 21:28 | 
| SteveA | then you can subscribe to the events you depend on, and see when they are done | 21:28 | 
| J1m | mgedmin, the bootstrap code actually depends on the subscriber ordering. | 21:28 | 
| mgedmin | oh? | 21:28 | 
| SteveA | to make this easier, i had the idea of extending the events system to allow you to subscribe to "IFooFinished event while IBarFinished event still being processed" events. | 21:29 | 
| J1m | As an implementation accident, subscribers of the same type are execited in order of registration. | 21:29 | 
| mgedmin | ok | 21:29 | 
| mgedmin | I'd like to have schoolbell running as a standalone app | 21:29 | 
| * SteveA waves hands some more | 21:29 | |
| mgedmin | with a SchoolBellApplication instance as the ZODB root object | 21:29 | 
| mgedmin | (zodb_conn.root()['Application']) | 21:30 | 
| * SteveA waves hands about ZODB root not being root of zope publishing, and a zcml:stick-an-app-at-this-url directive | 21:30 | |
| mgedmin | but if I <include package="zope.app" />, I have no chance to insert a bootstrap subscriber that would run before the default ones | 21:30 | 
| mgedmin | and, I believe, zope.app's configure.zcml includes the meta zcml file that defines <subscriber> | 21:31 | 
| * mgedmin murmurs something about "vapourware" and "hard deadlines" | 21:31 | |
| SteveA | mgedmin: in launchpad, i don't include zope.app, but include my own file that includes much of what zope.app includes | 21:31 | 
| mgedmin | anyway, I think I have workable a solution for my problem | 21:31 | 
| SteveA | notably excluding bootstrap stuff | 21:32 | 
| mgedmin | (I can open the ZODB manually, stick my object into root, and then publish the DatabaseOpened event myself) | 21:32 | 
| mgedmin | I just wanted to know if there was a "nicer" way | 21:32 | 
| mgedmin | or, alternatively, I wanted the zope 3 developers know about this "stick-my-application-instead-of-RootFolder" use case | 21:32 | 
| SteveA | the root folder should be rooted with a "stick the zope3 root folder at /" directive. you should be able to override this directive. | 21:33 | 
| SteveA | fancy working on that instead? ;-) | 21:33 | 
| J1m | My long term plan is to allow multiple root objects with some sort of mapping, as y'all have done. | 21:35 | 
| *** tvon|desk is now known as tvon | 21:36 | |
| *** tarek has quit IRC | 21:39 | |
| J1m | I'm adding an event that gets generated when a new local site is created | 21:47 | 
| J1m | Hm, but I'm not sure that this is what I want. :( | 21:48 | 
| J1m | SteveA, the problem with your idea of doing this when the instance is created is that you might want to add things later. | 21:49 | 
| *** bradb has quit IRC | 21:54 | |
| SteveA | at what point later? | 21:58 | 
| J1m | any point. You decide that you want your root to have a foo utility. You want to be able to arrange that existing instances can get this. | 22:01 | 
| J1m | You may decide you want more *after* the instance has been created. | 22:01 | 
| SteveA | that's the same problem as modifying any persistent data. it is an upgrade problem. | 22:04 | 
| SteveA | generations. | 22:04 | 
| J1m | No, I don't think so. | 22:04 | 
| J1m | Suppose you install a new application that wants something in the root. | 22:04 | 
| J1m | There is no previous generation. | 22:04 | 
| * SteveA resolves to think upon this :-) | 22:05 | |
| mgedmin | what about being able to run an "install" script when installing a schema manager? | 22:06 | 
| mgedmin | I was wondering about this when I studied generations | 22:06 | 
| * SteveA gets ready to leave the office | 22:06 | |
| J1m | right | 22:06 | 
| *** niemeyer has quit IRC | 22:07 | |
| *** SteveA has quit IRC | 22:12 | |
| *** stub has left #zope3-dev | 22:38 | |
| J1m | me tries mgedmin's install idea | 23:00 | 
| *** bskahan has quit IRC | 23:16 | |
| *** bskahan has joined #zope3-dev | 23:17 | |
| *** tvon has quit IRC | 23:18 | |
| *** tvon has joined #zope3-dev | 23:27 | |
| *** tvon|x31 has joined #zope3-dev | 23:33 | |
| *** vlado has joined #zope3-dev | 23:46 | |
| *** bskahan has quit IRC | 23:49 | |
| *** bskahan has joined #zope3-dev | 23:51 | |
| *** tvon has quit IRC | 23:54 | |
| *** tvon|x31 has quit IRC | 23:54 | |
Generated by irclog2html.py 4.0.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!