Log in
Forgot your password?
IRC log: CMF 2.0 Roadmap chat, 2005/09/12
Transcript of the chat from irc://irc.freenode.net/#zope-cmf.
**** BEGIN LOGGING AT Mon Sep 12 11:06:31 2005
Sep 12 11:06:31 <sebb> afternoon :)
Sep 12 11:06:35 <TresEquis> howdy
Sep 12 11:06:40 * sidnei shakes head
Sep 12 11:07:09 --> whit ([email protected]) has joined #zope-cmf
Sep 12 11:07:15 <TresEquis> I think we have a couple of agenda items beyond the current roadmap in the /topic
Sep 12 11:07:17 <TresEquis> hi, whit
Sep 12 11:07:28 <whit> hey TresEquis!
Sep 12 11:07:31 <whit> mornin
Sep 12 11:07:45 <TresEquis> first, to capture decisions in that roadmap
Sep 12 11:08:19 <TresEquis> the key points are to identify what integration points the layeerd frameworks (CPS, Plone) need to move forward with FIve-ification
Sep 12 11:08:20 <dataflake> darn, we missed the alpha ;)
Sep 12 11:08:50 <TresEquis> e.g., do we need to settle on a particular set of core event types
Sep 12 11:08:54 <TresEquis> heh
Sep 12 11:09:47 <TresEquis> are there views which will end up being reused across products?
Sep 12 11:10:09 <TresEquis> do we have a solution for the "local component registry" problem?
Sep 12 11:10:17 <sidnei> i would say for events, the basic object events + index + workflow, can't think of anything else
Sep 12 11:10:21 <runyaga> thats a good question since thats the blocker
Sep 12 11:10:36 <runyaga> sidnei: you can send tres the client portion of our auditlogger
Sep 12 11:10:41 <sidnei> local component registry: there's a local utility branch to be merged in five
Sep 12 11:10:53 <efge> I agree with sidney, events + index are a must
Sep 12 11:11:06 <TresEquis> what is "index"?
Sep 12 11:11:11 <whit> indexing
Sep 12 11:11:13 <sidnei> indexing
Sep 12 11:11:14 <whit> I think
Sep 12 11:11:15 <TresEquis> you mean, cataloguing?
Sep 12 11:11:18 <whit> yes
Sep 12 11:11:19 <sidnei> ya
Sep 12 11:11:20 <efge> yes
Sep 12 11:11:20 <runyaga> yes
Sep 12 11:11:26 * sidnei turns echo off
Sep 12 11:11:28 <efge> standard core indexes used by CMF
Sep 12 11:11:47 <runyaga> right
Sep 12 11:11:54 <efge> today there's a mix of "core" indexes needed by CMF to run, and "content" indexes for the user searches
Sep 12 11:12:13 <TresEquis> Why would the framework push "indexing events" beyond "basic object events"?
Sep 12 11:12:19 <TresEquis> ah, that is a different question
Sep 12 11:12:23 <alecm> expiry/effective events might be nice.
Sep 12 11:13:03 <efge> but yeah I misunderstood sidnei, if he was just talking about event types
Sep 12 11:13:18 <sidnei> scratch that, not sure why i said cataloguing events
Sep 12 11:13:21 <TresEquis> can we separate "creation" from "adding" events? It would mean redoing how the types tool uses the standard factories
Sep 12 11:13:48 <regebro> That could be a good thing to redo anyway.
Sep 12 11:13:50 <TresEquis> efge: are there any indexes which "user search" needs beyond the SearchableText one?
Sep 12 11:13:53 <efge> btw this work will need changing OFS too
Sep 12 11:14:04 <efge> TresEquis: for advanced search yes
Sep 12 11:14:12 <efge> dates, types, metadata, etc
Sep 12 11:14:15 <TresEquis> do any users beyond developers actually use it?
Sep 12 11:14:24 <sebb> yes
Sep 12 11:14:26 <sidnei> yes, object events (add/remove/move/copy) would be better placed on OFS.ObjectManager
Sep 12 11:14:26 <TresEquis> OK
Sep 12 11:14:28 <efge> oh yes, some customers love it
Sep 12 11:14:39 <sebb> "i want all PDFs published before yesterday"
Sep 12 11:14:41 <alecm> If CMFDefault used z3 add forms, then it wouldn't be hard to distinguish the two, otherwise there needs to be some sort of hack like ATs creation flag in place.
Sep 12 11:14:54 <TresEquis> we can't change Zope for this release
Sep 12 11:15:11 <TresEquis> which means we have to supply all that handling in the core containers
Sep 12 11:15:21 <efge> but we can provide suitable overloads in CMFCatalogAware or whatever with the intent of pushing that to Zope
Sep 12 11:15:28 <TresEquis> OK
Sep 12 11:15:40 <TresEquis> another question: do we target Zope 2.8.1? 2.9?
Sep 12 11:16:18 <alecm> TresEquis: Especially with Topic/Smart Folders many catalog indexes can be used by normal users.
Sep 12 11:16:21 <efge> I don't see why not 2.8.1, it has enough features no ?
Sep 12 11:16:37 <TresEquis> do we try to use a subset of the Z3 features which will continue to work on 2.9?
Sep 12 11:16:44 <TresEquis> e.g., we can't use services
Sep 12 11:16:56 <geoffd> zope 2.9 is out in dec, right? if we are looking at a release in that time frame, why not target 2.9?
Sep 12 11:17:23 <TresEquis> geoffd: the downside is that it makes "incremental adoption" harder
Sep 12 11:17:29 <efge> hm weel because we'd want to use it earlier, or test it on real projects
Sep 12 11:17:33 <TresEquis> upside is we don't have to worry about BBB
Sep 12 11:17:51 <efge> at that point I don't know what to target though
Sep 12 11:17:57 <TresEquis> sidnei: what is the "local registry" branch blocked on?
Sep 12 11:18:09 <TresEquis> because *that* might be a deal killer for 2.8.1
Sep 12 11:18:09 <geoffd> so 2.9 will add python 2.4 + z3 security, correct?
Sep 12 11:18:17 <regebro> It's harder to hit a moving target.
Sep 12 11:18:21 <sidnei> TresEquis: i think it was supposed to be merged after five 1.0, but nobody got around reviewing it
Sep 12 11:18:34 <TresEquis> is it based against the 1.0 branch?
Sep 12 11:18:39 <geoffd> regebro: true
Sep 12 11:18:48 <sidnei> TresEquis: yes, was done at the paris sprint
Sep 12 11:18:50 <efge> geoffd: the z3 security is still just a hope...
Sep 12 11:18:52 <TresEquis> Zope 2.9 will include Five 1.1 (or maybe 1.2)?
Sep 12 11:19:10 <regebro> TresEquis: correct.
Sep 12 11:19:12 <geoffd> TresEquis: so no huge changes?
Sep 12 11:19:22 <geoffd> (from 2.8.1)
Sep 12 11:19:28 <TresEquis> we would likely need to update Five to a 1.0.x which included local registries
Sep 12 11:19:40 <TresEquis> maybe Zope 2.8.2?
Sep 12 11:20:07 <regebro> Shouldn't be very big changes. It's the services thingy and and zc.forms, I guess.
Sep 12 11:20:08 <TresEquis> geoffd: I think 2.9 will include the security review to make Python 2.4 supported
Sep 12 11:20:44 <geoffd> ok - i think time based releases will make this all saner -- we can just consistently target current version of zope
Sep 12 11:20:54 <geoffd> and know we won't be more than 6 months behind
Sep 12 11:21:10 <dataflake> so CMF 2.0 -> Zope 2.8.x?
Sep 12 11:21:16 <TresEquis> but we definitely need stuff which is not in Zope right now
Sep 12 11:21:23 <geoffd> k
Sep 12 11:21:29 <dataflake> and CMF 2.1 -> Zope 2.9.x?
Sep 12 11:21:41 <TresEquis> or at least, I think losing local registries will be a deal breaker for some
Sep 12 11:21:56 <TresEquis> I guess we could see how far we get without them
Sep 12 11:22:15 <geoffd> what would be involved in getting them into, say zope 2.8.2 or 2.8.3?
Sep 12 11:22:29 <TresEquis> sidnei: would it be possible to lay down local registries via monkey patch?
Sep 12 11:22:53 <TresEquis> or was it a pervasive change?
Sep 12 11:22:59 <sidnei> TresEquis: that's about all it is *wink*
Sep 12 11:23:31 <sidnei> that's actually local utilities only, not local registries
Sep 12 11:23:50 <regebro> And that is a Five branch, right? Not Zope?
Sep 12 11:23:52 <sidnei> let me get a diff
Sep 12 11:23:52 <TresEquis> we're going to need local adapters and local views
Sep 12 11:23:59 <sidnei> yes, im aware of that
Sep 12 11:24:02 <TresEquis> k
Sep 12 11:24:54 <efge> remind me, the pb is that utilities didn't always get a context information ?
Sep 12 11:24:59 <TresEquis> Hmm, this doesn't work svn+ssh://codespeak.net/svn/z3/Five/branch/paris-localsitemanager-branch
Sep 12 11:25:48 <sidnei> TresEquis: define 'doesn't work'?
Sep 12 11:25:51 <regebro> I think the problem is that there are no sites and sitemanagers, right? So no local utilities.
Sep 12 11:26:22 <TresEquis> I couldn't check that out
Sep 12 11:26:32 <sidnei> TresEquis: https?
Sep 12 11:26:41 <TresEquis> Ah
Sep 12 11:26:45 <sidnei> regebro: i think actually we have a sitemanager and local utility
Sep 12 11:26:47 <TresEquis> forgot they used that
Sep 12 11:27:03 <regebro> sidnei: Yes, in the branch, or?
Sep 12 11:27:09 <sidnei> regebro: branch
Sep 12 11:27:32 <regebro> right. Is there any other problems/hangups for this?
Sep 12 11:28:00 <sidnei> cant remember of any issue
Sep 12 11:28:02 <efge> svn diff -r 9769 http://codespeak.net/svn/z3/Five/branch/paris-local-sitemanager-branch/
Sep 12 11:29:39 <regebro> So, then Zope 2.9 is not needed for this, right? So I'm a bit confused as to why we would need to target Zope 2.9.
Sep 12 11:30:32 <TresEquis> regebro: the Five shipped with Zope 2.8.1 doesn't have any of this support
Sep 12 11:30:32 <sidnei> efge: thanks
Sep 12 11:31:01 <sidnei> would it be reasonable to add add/delete/copy/move events into zope 2.8.x?
Sep 12 11:31:02 <TresEquis> we need local adapters / views / utilities to replace CMF tool lookup
Sep 12 11:31:04 <regebro> TresEquis: Sure, but we can require Five 1.x..
Sep 12 11:31:22 <regebro> For those who want to use it before Z2.9.
Sep 12 11:31:29 <TresEquis> it gets painful, but yes, I think so
Sep 12 11:31:38 <efge> sidnei: they'd be a backport from 2.9, but yes IMHO it would be very useful
Sep 12 11:31:56 <sidnei> i mean, would it be accepted?
Sep 12 11:32:04 <TresEquis> efge: does OFS have those events in 2.9?
Sep 12 11:32:20 <efge> TresEquis: not yet, I was speaking hypothetically
Sep 12 11:32:51 <TresEquis> ah, OK
Sep 12 11:32:55 <efge> what I mean is 2.9 needs them first anyway, and after that anything can be backporterd
Sep 12 11:33:15 <TresEquis> regebro: does the instancehome support allow local products to override those in SOFTWARE_HOME?
Sep 12 11:33:23 <TresEquis> I used to know that
Sep 12 11:33:58 <regebro> TresEquis: Sure.
Sep 12 11:34:15 <regebro> You just install a Five in instance/Products and that's the Five that will be used.
Sep 12 11:34:55 <TresEquis> OK
Sep 12 11:35:21 <TresEquis> does Five 1.1 have the local stuff merged?
Sep 12 11:35:35 <TresEquis> probably not, I would guess
Sep 12 11:35:42 <sidnei> not that i recall, im pretty sure not
Sep 12 11:37:00 <TresEquis> would we extend the 'utility_provider' to be 'component_regsitry', with API for adapters and views?
Sep 12 11:37:22 --> geekwad ([email protected]) has joined #zope-cmf
Sep 12 11:37:57 <TresEquis> Is that Michel?
Sep 12 11:38:22 <sidnei> TresEquis: sounds like it
Sep 12 11:38:24 <efge> given his hostname I'd say yes
Sep 12 11:38:26 <geekwad> This is not Michel, but a different confusingly named individual.
Sep 12 11:38:36 <TresEquis> that would never happen :)
Sep 12 11:38:52 <TresEquis> are you the spider racing Mike Pelletier? ;)
Sep 12 11:39:14 <geekwad> Yes, I am. But I just came for the fun of it.
Sep 12 11:39:21 <TresEquis> lovely
Sep 12 11:40:19 <TresEquis> you and I just missed overlap at Digital Creations, I think
Sep 12 11:41:02 <geekwad> I think we met durring PyCon 8?
Sep 12 11:41:14 <TresEquis> yup, I was interviewing at that point
Sep 12 11:41:43 <TresEquis> in Arlington, VA, right? Snowed in?
Sep 12 11:41:45 <geekwad> You had a very respectable beard and are awesomely well-mannered, IIRC.
Sep 12 11:41:49 <encolpe> A+
Sep 12 11:41:56 <-- encolpe has quit ("Leaving")
Sep 12 11:42:07 <runyaga> so whats next?
Sep 12 11:42:15 <sebb> how about "are there views which will end up being reused across products?"
Sep 12 11:42:17 <runyaga> i turn into a pumpkin in 16 minutes
Sep 12 11:42:27 <sebb> (I was wondering what that meant precisely)
Sep 12 11:42:29 <TresEquis> we need to get a version of Five which supports our needs
Sep 12 11:42:44 <runyaga> TresEquis: so whos responsibility is that? could that happen at the goldegg sprint in 2 weeks?
Sep 12 11:42:59 <sidnei> TresEquis: our needs being local views and adapters?
Sep 12 11:43:03 <TresEquis> runyaga: could be: Faassen will be there
Sep 12 11:43:12 <TresEquis> sidnei: yes, and merging your work
Sep 12 11:43:24 <regebro> I currently can not think of any views used across products.
Sep 12 11:43:29 <runyaga> right.. i think its best for it to happen when t here is a larger group to support and review the work
Sep 12 11:43:39 <TresEquis> either that, or we need to ship a separate product which monkey patches the "core" Five
Sep 12 11:43:44 <runyaga> i cant think of views across products -- possibly folder contents but i would just punt on reuse for now
Sep 12 11:44:01 <sidnei> it can even be completely out of five, it doesn't matter
Sep 12 11:44:18 <TresEquis> sidnei: that might be better than hacking five
Sep 12 11:44:40 <TresEquis> Can we agree that the responsibility for emitting events will move into the views?
Sep 12 11:44:44 <runyaga> yes
Sep 12 11:44:49 <regebro> We'll sync a Five release with CMF 2.0 if needed. No problems.
Sep 12 11:44:50 <runyaga> + 1
Sep 12 11:45:09 <sidnei> TresEquis: that includes add/move/rename/delete events?
Sep 12 11:45:14 <TresEquis> yes
Sep 12 11:45:17 <runyaga> sidnei: yes
Sep 12 11:45:24 <TresEquis> I think those could be emitted by the container views
Sep 12 11:45:27 <runyaga> FolderContentsView could emit 'em
Sep 12 11:45:28 <efge> TresEquis: how can the responsibility move when we don't send events today ?
Sep 12 11:45:54 <runyaga> efge: some ppl may monkeypatch OFS.ObjectManager
Sep 12 11:45:56 <TresEquis> content objects currently send them to "faux" event channels (workflow tool and catalog)
Sep 12 11:46:01 <efge> ah those
Sep 12 11:46:04 <efge> yes
Sep 12 11:46:17 <TresEquis> I want content objects to get much dumber
Sep 12 11:46:23 * runyaga nods
Sep 12 11:46:30 <sidnei> so, cmfcatalogaware would die?
Sep 12 11:46:38 <efge> runyaga: everybody monkey patches OFS.ObjectManager anyway :) so we'd better be careful
Sep 12 11:46:40 <TresEquis> I think so
Sep 12 11:47:09 <runyaga> so i think container views are best.. and we can do that fairly easy
Sep 12 11:47:12 <sidnei> trying to figure out what this means for webdav for example
Sep 12 11:47:14 <runyaga> i would like to chat about events
Sep 12 11:47:22 <TresEquis> OK
Sep 12 11:47:24 <sidnei> as there's no 'views' in webdav, it would move to webdav.Resource
Sep 12 11:47:28 <alecm> Why would we be providing the events with views rather than adapters?
Sep 12 11:48:00 <sidnei> alecm: both views and adapters can fire events, just 'core code' should not do so
Sep 12 11:48:01 <efge> alecm: the views are the component that should decide to send events
Sep 12 11:48:26 <sidnei> maybe adapters shouldnt fire events
Sep 12 11:48:32 * sidnei shuts up
Sep 12 11:48:59 <TresEquis> the webdav PUT handler is basically a view
Sep 12 11:49:05 <efge> alecm: because core code should be core and not deal too much with the framework, but with the content and the application itself
Sep 12 11:49:13 <TresEquis> in fact, we could move that logic there
Sep 12 11:49:20 <efge> OTOH I'm not sure some events don't have their place in the core sometimes...
Sep 12 11:49:29 <sidnei> TresEquis: there == webdav.Resource?
Sep 12 11:49:41 <TresEquis> there == "a view registered for PUT"
Sep 12 11:49:53 <sidnei> TresEquis: what about MOVE and COPY?
Sep 12 11:50:10 <TresEquis> maybe we register those as views, too
Sep 12 11:50:46 <sidnei> doesn't really make sense to make those views in zope2, it's soooooooo much shit to keep track of i doubt anyone can implement a view from scratch and get it right in one year's timeframe *wink*
Sep 12 11:51:22 <TresEquis> webdav.Resource can't do what we want, though
Sep 12 11:51:34 <TresEquis> we'd end up reimplementing almost all of it
Sep 12 11:51:53 <TresEquis> runyaga: what else needs addressing about events?
Sep 12 11:52:01 <runyaga> oh sorry
Sep 12 11:52:03 <sidnei> maybe we factor out existing code into views and have webdav.Resource delegate to views
Sep 12 11:52:17 <TresEquis> in Zope 2.8.x?
Sep 12 11:52:18 <runyaga> one feature i would love tto try to stuff in
Sep 12 11:52:19 <sidnei> i doubt anyone would care to override those views thouhg
Sep 12 11:52:26 <runyaga> is have events be flushed on trnx boundaries
Sep 12 11:52:38 <sidnei> TresEquis: yeah, why not
Sep 12 11:52:40 <runyaga> nuxeo/cps and enfold/plone already have this code
Sep 12 11:52:53 <TresEquis> this is the 'auditlogger' stuff?
Sep 12 11:52:56 <runyaga> mainly just seeing if that would be ok
Sep 12 11:53:09 <runyaga> for us - its auditlogger; i think for cps its so they dont reindex object's more than 1
Sep 12 11:53:27 <alecm> That would be excellent to have IMHO, especially for AT which is terrible in that regard.
Sep 12 11:53:36 <whit> damn tootin
Sep 12 11:53:45 <runyaga> alecm: right
Sep 12 11:53:48 <efge> runyaga: yeah
Sep 12 11:53:52 <TresEquis> does that require hacking the global event service? Or do we register an "aggregating channel"?
Sep 12 11:54:13 <runyaga> i believe currently in our impl its global
Sep 12 11:54:31 <sidnei> it has nothing to do with the event service
Sep 12 11:54:31 <runyaga> efge: you guys have events local to portal instance?
Sep 12 11:54:36 <efge> just have the subscribers push the events to a global queue, that's triggerd at the end of the transaction
Sep 12 11:54:42 <runyaga> ok
Sep 12 11:54:42 <sidnei> it's just a subscriber that is also transaction-aware
Sep 12 11:54:47 <efge> runyaga: yes, the events are sent using a context
Sep 12 11:54:52 <sidnei> yes, same thing here
Sep 12 11:54:58 <efge> and we have a portal_eventservice
Sep 12 11:55:07 <TresEquis> like a 'portal_events' tool?
Sep 12 11:55:08 <TresEquis> ah
Sep 12 11:55:25 <TresEquis> does it function as the local channel for other subscribers, too?
Sep 12 11:55:57 <TresEquis> how does it manage the "coalescing" of similar events?
Sep 12 11:55:58 <efge> in cps it's only used for events, what other subscribers do you have in mind ?
Sep 12 11:56:12 <TresEquis> catalog and workflow tools should be event subscribers
Sep 12 11:56:16 <efge> TresEquis: we leave that to further processing, the event service does not do that
Sep 12 11:56:18 <TresEquis> but only for events in a given site
Sep 12 11:56:35 <TresEquis> do you publish events only at TXN boundary?
Sep 12 11:56:59 <efge> we publish events all the time
Sep 12 11:57:14 <efge> some subscribers delay their processing to txn boundary
Sep 12 11:57:18 <TresEquis> ok
Sep 12 11:57:29 <sidnei> pretty much like 'queue catalog'
Sep 12 11:57:36 <efge> coalescing events is hard though, in general
Sep 12 11:57:43 <sidnei> subscribers queue up events which are processed at txn boundary
Sep 12 11:57:51 <efge> so you want to leave that to specialized code that knows about each event's semantics
Sep 12 11:58:01 <TresEquis> OK
Sep 12 11:58:03 <sidnei> the 'queue' could be smart and coalesce similar events
Sep 12 11:58:07 <alecm> Makes sense to leave it to the subscriber, not all event actions will need this kind of handling. And such a queue may not make sense for every subscriber.
Sep 12 11:58:16 <runyaga> ok
Sep 12 11:58:18 <efge> also, some parts of the framework may not deal well with delayed events
Sep 12 11:58:37 <efge> imagine some security change and a reindexing of allowedRolesAndUsers
Sep 12 11:58:38 <TresEquis> delayed events could be useful for stuff which is "non-transactional"
Sep 12 11:58:46 <TresEquis> like sending mail
Sep 12 11:58:52 <whit> exactly
Sep 12 11:58:58 <efge> if you delay indexing to the end, any catalog search done meanwhile will get different results
Sep 12 11:59:02 <TresEquis> maybe we should just bundle Jens' transactional mailhost
Sep 12 11:59:02 <whit> a sort of defer till x behavior
Sep 12 11:59:31 <TresEquis> efge: within the same request, you mean?
Sep 12 11:59:35 <efge> yes
Sep 12 11:59:50 <efge> the same txn really
Sep 12 11:59:56 <runyaga> ok pumpkln time.. anything else? whats the next steps TresEquis ?
Sep 12 12:00:00 <dataflake> tres: i wouldn't mind
Sep 12 12:00:33 <TresEquis> runyaga: I'll upload log, and modify the roadmap accordingly
Sep 12 12:00:42 <runyaga> TresEquis: thanks
Sep 12 12:00:48 <regebro> The redoing of how typetool uses factories could be of interest as well.
Sep 12 12:00:52 <TresEquis> efge: you had some question about catalog indexing
Sep 12 12:01:07 <TresEquis> regebro: yes, I think we need to move away from the "stock" Z2 factories
Sep 12 12:01:16 <efge> to finish with events: I'd like to have a boolean on the catalog for instance that says "delay indexings"
Sep 12 12:01:47 <efge> TresEquis: not really questions, just some remarks about the different classes of indexes we use really
Sep 12 12:01:53 <TresEquis> OK
Sep 12 12:02:02 <regebro> TresEquis: At least that would open up for making things much more Zope3-ish, by getting rid of factory_type_information. But now we are discussing several issues at once.
Sep 12 12:02:10 <TresEquis> yup
Sep 12 12:02:37 <whit> could you put this on the event, like delay until x happens(another event, txn, etc)
Sep 12 12:03:14 <TresEquis> efge: I think maybe we would have a "delayed" channel, and you could swtich the catalog to subscribe to it when you wanted the delay
Sep 12 12:03:25 <efge> whit I'd say that's too complex for an initial framework, maybe later
Sep 12 12:03:33 <TresEquis> it would just queue up *all* events until TXN boundary
Sep 12 12:04:03 <TresEquis> enfold's logging code might be the basis for the "delayed" channel
Sep 12 12:04:16 <alecm> It might make sense to allow the event emmitter to determine whether the event is delayable (provided the subscriber supports and enables it), as whit suggests.
Sep 12 12:04:17 <efge> hm yeah we still have to "ordering of subscribers" problem somwhere there...
Sep 12 12:04:39 <TresEquis> sidnei: does auditlogger get fired during 'tpc_vote'?
Sep 12 12:05:04 <TresEquis> or do you monkeypatch the publisher to trigger it before the actual commit?
Sep 12 12:05:34 <efge> there's a before commit hook in ZODB now
Sep 12 12:05:44 <TresEquis> in 2.8?
Sep 12 12:05:53 <alecm> yes in 2.8
Sep 12 12:05:54 <TresEquis> cool
Sep 12 12:06:04 <TresEquis> I missed that
Sep 12 12:06:17 <alecm> _before_transaction_commit
Sep 12 12:06:27 <TresEquis> Summarizing:
Sep 12 12:06:57 <TresEquis> - do we add a 'portal_eventservice' tool, which skins / views use as their point of publishing?
Sep 12 12:07:08 <TresEquis> or is the tool where they get subscribed only?
Sep 12 12:07:13 <sidnei> TresEquis: not quite sure it's tpc_vote, let me check
Sep 12 12:07:48 <efge> TresEquis: in the context of Z3 we definitely don't want a portal_eventservice, it's a dead chicken in Z3
Sep 12 12:07:53 <whit> yeah
Sep 12 12:07:56 <sidnei> TresEquis: it's in tpc_finish
Sep 12 12:08:08 <whit> can we start migrating getToolByName to look up utilities
Sep 12 12:08:10 <efge> each tool can provide a subscriber that's context aware and dispatches accordingly
Sep 12 12:08:10 <TresEquis> that's too late for generic event handling
Sep 12 12:08:29 <TresEquis> whit: adapters, mostly
Sep 12 12:08:31 <sidnei> yes, might be too late, but it's just perfect for logging
Sep 12 12:08:45 <TresEquis> sidnei: right
Sep 12 12:08:57 <TresEquis> 'tpc_finish' is not allowed to fail
Sep 12 12:09:22 <TresEquis> I think the before commit hook might be a better point for generic processing
Sep 12 12:09:50 <alecm> doing complex things like catalog indexing post-transaction seems far too dangerous.
Sep 12 12:09:57 <TresEquis> yup
Sep 12 12:10:07 <TresEquis> impossible, even
Sep 12 12:10:19 <efge> TresEquis: I added the hook to ZODB because that's where we needed it :)
Sep 12 12:10:50 <TresEquis> who gets notified? All the "jars" associated with the TXN?
Sep 12 12:10:59 <efge> you register a callable
Sep 12 12:11:08 <efge> with parameters
Sep 12 12:11:12 <efge> and it gets called
Sep 12 12:11:14 <TresEquis> how does it daisy chain?
Sep 12 12:11:42 <efge> they all get called until no more are left, if that's what you ask
Sep 12 12:11:51 <TresEquis> ah, ok
Sep 12 12:12:16 <efge> anguenot wanted to add a priority/ordering mechanism but Jim was of the opinion that ZODB was not the correct layer to do that
Sep 12 12:12:32 <TresEquis> efge: does CPS' portal_eventservice function as the point of publication, the "local subscription point", or both?
Sep 12 12:13:00 <efge> both. But it's pretty old, I'd redesign it differently today
Sep 12 12:13:09 <anguenot> efge: whatever we have our TransactionManager now :)
Sep 12 12:13:41 <anguenot> if you guys wanna check an example
Sep 12 12:13:42 <TresEquis> Would you have events published to the global event "service"?
Sep 12 12:13:51 <anguenot> yup
Sep 12 12:14:13 <efge> TresEquis: with the expectation that some subscribers would redispatch them locally to some tools, yes
Sep 12 12:14:23 <TresEquis> I think each site needs some way to have a filtered event channel
Sep 12 12:14:40 <efge> hm...
Sep 12 12:14:42 <TresEquis> so that tools can subscribe to events which are "local" to that site
Sep 12 12:14:57 <TresEquis> it would be that "redispatch" thing
Sep 12 12:15:30 <TresEquis> I'm not sure how to make subscriptions persistent, however
Sep 12 12:15:44 <efge> I think persistent subscriptions are bad
Sep 12 12:15:51 <TresEquis> I know how we did it in the 'Events' and 'Listeners' products
Sep 12 12:15:52 <efge> we have them and they're a pain
Sep 12 12:16:29 <efge> persistent stuff gets out of sync with the code...
Sep 12 12:16:42 <TresEquis> you can end up with "global" code which knows too much about the persistent store if you go the other route
Sep 12 12:17:42 <efge> we should brainstorm that out at goldegg maybe
Sep 12 12:17:52 <TresEquis> You have to factor stuff such that ZCML is insulated from "local policy" somehow
Sep 12 12:17:53 <TresEquis> OK
Sep 12 12:20:11 <efge> sooo... what else ?
Sep 12 12:20:21 <TresEquis> regebro: do you want to add anything about containerless factories?
Sep 12 12:20:58 <regebro> No, not really, just that it would be nice to not requre factory_type_information...
Sep 12 12:21:12 <TresEquis> oh, speaking of that
Sep 12 12:21:19 <regebro> ...and that more or less requires a refactoring to that fti uses Five.
Sep 12 12:21:31 <TresEquis> what do folks think about splitting out GenericSetup?
Sep 12 12:22:09 <efge> +1 if that makes the development of CMFSetup faster/simpler
Sep 12 12:22:13 <TresEquis> The only downside I can think of is that it becomse a dependency for CMF
Sep 12 12:22:35 <TresEquis> but it does make it possible for non-CMF code to reuse the core
Sep 12 12:22:43 <alecm> +1 from me, especially if actions can become purely local configuration.
Sep 12 12:22:54 <whit> I second that
Sep 12 12:23:04 <TresEquis> I think that having the FTIs go away (in code) is a big win
Sep 12 12:23:32 <TresEquis> dataflake: you pointed out that the types tool UI expects the registry of FTIS
Sep 12 12:23:38 <TresEquis> we will need a way to fix that
Sep 12 12:23:53 <dataflake> tres: yes, the ZMI dropdown when you're in the types tool
Sep 12 12:24:08 <regebro> alecm: What do you think of when you say "local" in "local configuration". :)
Sep 12 12:24:47 <TresEquis> I want the FTI info to become "data" (in setup profiles) rather than code ('factory_type_information' at module scope)
Sep 12 12:24:58 <efge> +10 on that
Sep 12 12:25:04 <TresEquis> I don't know what alecm wants ;)
Sep 12 12:25:05 <regebro> Sounds reasonable, yes.
Sep 12 12:25:21 <dataflake> yes, +100
Sep 12 12:25:30 <TresEquis> Except for the tool UI, I think we could already go there
Sep 12 12:25:31 <alecm> regebro: Product configuration really. Something I can stuff into some XML file in Plone or whatever custom site product and not worry about.
Sep 12 12:25:41 <dataflake> my CMF product did away with them yesterday
Sep 12 12:25:51 <dataflake> products
Sep 12 12:25:53 <sidnei> for me, i think most of the actions make sense as 'global' actions, with an option of turning them 'local'
Sep 12 12:26:15 <TresEquis> sidnei: do you mean overriding them within a given folder in a site?
Sep 12 12:26:24 <sidnei> yes
Sep 12 12:26:26 <alecm> sidnei: yes, I was abusing "local" there.
Sep 12 12:26:28 <TresEquis> or do you mean overriding them in one site within a Zope instance?
Sep 12 12:26:28 <regebro> alecm: OK. CMFonFive currently makes menuItems into actions, but maybe this should be moved to CMFSetup configurations instead?
Sep 12 12:26:31 <efge> the tool add menu will need to consult the registry, but other places in zope do that
Sep 12 12:26:41 <sidnei> well, the later
Sep 12 12:26:46 <sidnei> why not both *wink*
Sep 12 12:27:13 <TresEquis> we have a couple of implementations of "folders-with-local-actions" lying around
Sep 12 12:27:42 <sidnei> my point is, nobody actually customizes 'view' and 'edit' actions for example, unless really really need so
Sep 12 12:28:01 <sidnei> so, having them persisted in tools just make migration forward harder
Sep 12 12:28:17 <TresEquis> What gets customized is the labels
Sep 12 12:28:31 <TresEquis> but I think that CMFSetup can make migration simpler
Sep 12 12:28:40 <efge> overriding things for just one folder/document is really a content problem, quite different
Sep 12 12:28:51 <efge> or metacontent maybe
Sep 12 12:29:06 <TresEquis> dump your tool configuration to a profile, and then find a way to reapply after upgrading software
Sep 12 12:29:19 <TresEquis> efge: agreed
Sep 12 12:29:41 <TresEquis> there are lots of cases where type-based policy may need instance-specific override
Sep 12 12:29:52 <sidnei> wouldn't it be simple to have just *customizations* dumped to a profile, and all actions be global, in zcml or similar?
Sep 12 12:30:05 <efge> sidnei: if you use a framework like plone/cps, indeed you don't change view or edit actions, that's all in the framework's config and doesn't change. but CMFSetup answers that need
Sep 12 12:31:22 <efge> sidnei: there's a tradeoff between simplicity of upgrading the code without changing persistent stuff, and the potential surprised if you upgrade the code and some default change
Sep 12 12:31:40 <alecm> Even if FTIs were no longer required, would they still be allowed (e.g. TTW)? So that people in shared hosting situations could add trivial types in the ZMI.
Sep 12 12:31:56 <efge> suppose a customer relies on the default for some action, and you change that behind his back... I'd rather be fully explicit, and dump/load everything using CMFSetup
Sep 12 12:32:24 <sidnei> i dont' think cmfsetup is the magical solution to that. in fact it will have the exact same issue
Sep 12 12:32:25 <TresEquis> alecm: I think we'll have to allow for that kind of ues
Sep 12 12:32:46 <TresEquis> the hard part of that will be enabling locally-customized templates
Sep 12 12:33:12 <TresEquis> sidnei: at least the setup tool allows you to compare configs
Sep 12 12:33:21 <TresEquis> so you know what has changed
Sep 12 12:33:36 <TresEquis> either in the ZODB or on disk
Sep 12 12:33:48 <sidnei> yeah, i guess that helps
Sep 12 12:34:12 <TresEquis> we might even come up with a way to create "patch" profiles
Sep 12 12:34:16 <efge> to summarize my position: I'm all for removing the ugly fti dicts, but I still want a persistent config in the types tool
Sep 12 12:34:37 <TresEquis> which coupld be applied after an upgrade
Sep 12 12:35:28 <TresEquis> efge: I am also looking to break the dependency on the "old school" factories, which create objects in place
Sep 12 12:35:45 <TresEquis> so that we can separate the "created" from the "added" events, for instance
Sep 12 12:36:07 <TresEquis> that could wait, I guess
Sep 12 12:36:30 <efge> hm that's hard
Sep 12 12:36:38 <regebro> To get rid of ftis we need to refactor the whole shebang anyway so...
Sep 12 12:37:45 <efge> I need to think about remonving ftis, on one hand I'm attracted to it, on the other hand it makes some things much more complex... sidnei I see your point
Sep 12 12:37:48 <TresEquis> regebro: we could dump the gnarly FTI data structures without killing off FactoryTypeInformation (which we need for BBB)
Sep 12 12:38:49 <TresEquis> the data structures just duplicate what is in the CMFSetup profile, any way
Sep 12 12:38:51 <regebro> Well, yes, but I think we would need to reimlement much of FactoryTypeInformation.
Sep 12 12:39:14 <TresEquis> for my "containerless creation", yes
Sep 12 12:39:43 <regebro> Anyway, really. FTI duplicates a lot of what is done in zcml now, and we would rather want to make FTI wrap Zope3 factory type thingies than the otehr way around.
Sep 12 12:40:09 <TresEquis> ZC's Z4I has separate Z3TypeInformation objects
Sep 12 12:40:15 <TresEquis> which handle that case
Sep 12 12:40:28 <regebro> ok, interesting.
Sep 12 12:40:57 <regebro> I tried making those myself, and ended up with a stupid amount of code duplication.
Sep 12 12:41:24 <TresEquis> I'm not saying that those things don't have such a problem ;)
Sep 12 12:42:11 <regebro> But OK; we can see two separate issues:
Sep 12 12:42:13 <regebro> 1. moving fti data to CMFSetup XML.
Sep 12 12:42:33 <regebro> 2. refactoring type information to separate adding and creation.
Sep 12 12:43:28 <TresEquis> the refactoring requires setting up a separate registry of "factories" (separate from the one which drives the ZMI add list)
Sep 12 12:43:59 <TresEquis> we could probably reuse the <content> directive for that ;)
Sep 12 12:44:31 <TresEquis> #1 is an almost pure win, however
Sep 12 12:44:38 <TresEquis> except for the TTI UI
Sep 12 12:44:53 <TresEquis> and the goofy "CMFCore Content" add list entry ;)
Sep 12 12:45:31 <dataflake> are those ZMI entries for "FOO content" even desirable?
Sep 12 12:45:36 <TresEquis> No
Sep 12 12:45:39 <dataflake> i never found them useful
Sep 12 12:45:46 <regebro> And I wouldn't mind being able to use a <content> and <addMenuItem> directive for Zope+Five without CMF either.
Sep 12 12:45:56 <TresEquis> they just encourage users to create broken content objects
Sep 12 12:46:01 <dataflake> yeah, exactly
Sep 12 12:46:24 <TresEquis> I think we can wait for #2, unless somebody gets inspired
Sep 12 12:46:30 <regebro> OK.
Sep 12 12:47:09 <TresEquis> I think we decided to use the same events which Z3 currently declares for creation, adding, moving, deleting, etc.
Sep 12 12:47:30 <TresEquis> we will need events for workflow state changes (likely a before and an after)
Sep 12 12:47:54 <TresEquis> what others? Role changes (e.g., to handle reindexing security)?
Sep 12 12:48:50 <efge> yes security changes need to have their own events
Sep 12 12:49:12 <efge> because they can be special-cased an thus much faster
Sep 12 12:49:46 <efge> we need content change events, I'm not sure what Z3 has at this point
Sep 12 12:50:01 <efge> one question was: what is a content change :)
Sep 12 12:50:23 <TresEquis> I think they were trying for "elegant, general"
Sep 12 12:50:28 <efge> ie some content changes are low level and not user visible, others are visible, some should provoke reindexings, not others...
Sep 12 12:50:33 <TresEquis> I'm willing to live with "simple and stupid"
Sep 12 12:51:09 <efge> I hope that's not a marital remark :)
Sep 12 12:51:18 <TresEquis> heh, nope
Sep 12 12:51:24 <alecm> expiry/effective events (which would need to be triggered by externally) would be a big improvement.
Sep 12 12:51:27 <efge> anyway I've also always been concerned about move events
Sep 12 12:51:43 <efge> I really don't like the fact that move events are dispatched to all subobjects
Sep 12 12:51:47 <efge> the cost may be huge
Sep 12 12:52:14 <TresEquis> we can try for a dumber one
Sep 12 12:52:14 <efge> I'd want a simple basic move event, then if some subscribers wants to recurse in the children let him do it
Sep 12 12:52:27 <TresEquis> and let the catalog optimize, for instance
Sep 12 12:52:41 <efge> this also applies to paste and del of course
Sep 12 12:52:53 <alecm> efge: Many object types may want to know when their path changes though.
Sep 12 12:52:54 <efge> I we can achieve that then yes that'd be great
Sep 12 12:53:04 <TresEquis> paste from copy needs to do something
Sep 12 12:53:15 <efge> alecm: sure but as an added option
Sep 12 12:53:20 <efge> not by default
Sep 12 12:53:21 <TresEquis> alecm: content objects need to get dumber
Sep 12 12:53:51 <TresEquis> especially if the catalog, etc. (and UID -> location stuff) gets smarter about moves
Sep 12 12:54:24 <TresEquis> given adequat UID-location mapping, content can always find out where it is
Sep 12 12:54:27 <alecm> Yes, but these are the views we are talking about. Would we make it so that a move event on a folderish object triggered a recursive reindex on its own?
Sep 12 12:54:50 --- sidnei is now known as sid|fud
Sep 12 12:55:01 <TresEquis> the catalog might be able to fix up the subobjects without even consulting them
Sep 12 12:55:22 <TresEquis> although some indexes might not work
Sep 12 12:55:31 <efge> but it's up to the catalog to decide that
Sep 12 12:55:35 <TresEquis> e.g., if the index is based on an acquired property
Sep 12 12:55:51 <alecm> It's keeping the uid-location mapping in sync that's the problem. Having the catalog do that sort of housekeeping would be nice though.
Sep 12 12:55:54 <efge> then the index would be flagged as "context dependent" or something
Sep 12 12:56:16 <TresEquis> the UID location tool would be a subscriber of the events
Sep 12 12:56:17 <alecm> TresEquis: Can/should the catalog really know if an index comes from an acquired property or not?
Sep 12 12:56:27 <TresEquis> it doesn't *now*
Sep 12 12:56:28 <whit> if the indexing were done by an adapter, the adapter could manage that
Sep 12 12:56:51 <whit> or communicate it to the catalog
Sep 12 12:57:10 <efge> alecm: if it helps optimize the speed of the common case, it'd be worthwhile to be able to instruct the catalog about it
Sep 12 12:57:16 <TresEquis> efge wants to avoid having to consult each object recursively during a move
Sep 12 12:57:33 <alecm> Yes, for some objects it may be acquired otherwise not. An adapter would be useful here.
Sep 12 12:57:36 <whit> that being, "this index is context dependent for this object"
Sep 12 12:57:47 * alecm too, recursive always sucks.
Sep 12 12:57:53 <efge> TresEquis: actually I just wanted to not have an event for each subobject, but I agree with your point
Sep 12 12:58:28 <TresEquis> OK, I'm going to need to bail pretty soon
Sep 12 12:58:47 <TresEquis> I plan to upload transcript and update the roadmap document by tomorrow morning
Sep 12 12:58:48 <whit> cool....one quick thing about cataloguing
Sep 12 12:58:52 <TresEquis> k
Sep 12 12:59:18 <whit> the plonista have been working on some way to indirectly index things by adapter
Sep 12 12:59:25 <TresEquis> right
Sep 12 12:59:46 <TresEquis> adapting the object to an "ICataloguableData" interface, or something?
Sep 12 12:59:50 <whit> we were discussing a name adapter that implements IIndexable for an IFace
Sep 12 13:00:04 <whit> name == index
Sep 12 13:00:08 <whit> or column
Sep 12 13:00:14 <TresEquis> OK
Sep 12 13:00:33 <whit> we also were discussing that an extra directive might really simplify this
Sep 12 13:01:02 <whit> something like
Sep 12 13:01:06 <whit> cmf:indexable for:ISomething attributes='SearchableText path folder_order'
Sep 12 13:01:33 <regebro> Works for me.
Sep 12 13:02:01 <regebro> I've long wanted a way to define in teh product which inexes should exist.
Sep 12 13:02:05 <TresEquis> would that be sugar for a set of named adapters?
Sep 12 13:02:19 <whit> yes
Sep 12 13:02:22 <whit> exactly
Sep 12 13:02:23 <TresEquis> +1, then
Sep 12 13:04:07 <TresEquis> any Parthian shots?
Sep 12 13:04:43 <TresEquis> I'm going to be asking for help from Enfold / Nuxeo on the "deferred events" bit
Sep 12 13:05:11 <TresEquis> and from sidnei / regebro for the "local registry" stuff
Sep 12 13:05:42 <regebro> ok.
Sep 12 13:06:31 <whit> for the index stuff, should we just submit an implementation when we have some code to show?
Sep 12 13:07:29 <TresEquis> can you send me a sample of a directive? I'll include it in the roadmap doc
Sep 12 13:07:33 <TresEquis> [email protected]
Sep 12 13:07:50 <whit> sure!
Sep 12 13:09:08 <TresEquis> Thanks very much to all for participating
Sep 12 13:09:26 <TresEquis> I look forward to seeing some of you in Austria
Sep 12 13:09:38 <whit> cya in vienna TresEquis!
Sep 12 13:09:52 <regebro> See ya!
Sep 12 13:09:57 <efge> bye all
Sep 12 13:10:07 <alecm> Thank you TresEquis
Sep 12 13:16:42 * sid|fud hints those that don't know spanish that 'TresEquis' translates to 'Triple X' :)
Sep 12 13:19:12 <-- geekwad ([email protected]) has left #zope-cmf ("Kopete 0.10 : http://kopete.kde.org")
Sep 12 13:19:13 --- sid|fud is now known as sidnei
Sep 12 13:33:24 <-- alecm (n=alecpm@plone/alecm) has left #zope-cmf ("Konversation terminated!")
Sep 12 13:33:26 <-- dataflake has quit ()
Sep 12 13:42:50 --> RaFromBRC (n=RaFromBR@plone/rafrombrc) has joined #zope-cmf
Sep 12 13:44:03 <-- regebro has quit ("smoking!")
Sep 12 14:01:53 <-- yuppie ([email protected]) has left #zope-cmf
Sep 12 11:06:31 <sebb> afternoon :)
Sep 12 11:06:35 <TresEquis> howdy
Sep 12 11:06:40 * sidnei shakes head
Sep 12 11:07:09 --> whit ([email protected]) has joined #zope-cmf
Sep 12 11:07:15 <TresEquis> I think we have a couple of agenda items beyond the current roadmap in the /topic
Sep 12 11:07:17 <TresEquis> hi, whit
Sep 12 11:07:28 <whit> hey TresEquis!
Sep 12 11:07:31 <whit> mornin
Sep 12 11:07:45 <TresEquis> first, to capture decisions in that roadmap
Sep 12 11:08:19 <TresEquis> the key points are to identify what integration points the layeerd frameworks (CPS, Plone) need to move forward with FIve-ification
Sep 12 11:08:20 <dataflake> darn, we missed the alpha ;)
Sep 12 11:08:50 <TresEquis> e.g., do we need to settle on a particular set of core event types
Sep 12 11:08:54 <TresEquis> heh
Sep 12 11:09:47 <TresEquis> are there views which will end up being reused across products?
Sep 12 11:10:09 <TresEquis> do we have a solution for the "local component registry" problem?
Sep 12 11:10:17 <sidnei> i would say for events, the basic object events + index + workflow, can't think of anything else
Sep 12 11:10:21 <runyaga> thats a good question since thats the blocker
Sep 12 11:10:36 <runyaga> sidnei: you can send tres the client portion of our auditlogger
Sep 12 11:10:41 <sidnei> local component registry: there's a local utility branch to be merged in five
Sep 12 11:10:53 <efge> I agree with sidney, events + index are a must
Sep 12 11:11:06 <TresEquis> what is "index"?
Sep 12 11:11:11 <whit> indexing
Sep 12 11:11:13 <sidnei> indexing
Sep 12 11:11:14 <whit> I think
Sep 12 11:11:15 <TresEquis> you mean, cataloguing?
Sep 12 11:11:18 <whit> yes
Sep 12 11:11:19 <sidnei> ya
Sep 12 11:11:20 <efge> yes
Sep 12 11:11:20 <runyaga> yes
Sep 12 11:11:26 * sidnei turns echo off
Sep 12 11:11:28 <efge> standard core indexes used by CMF
Sep 12 11:11:47 <runyaga> right
Sep 12 11:11:54 <efge> today there's a mix of "core" indexes needed by CMF to run, and "content" indexes for the user searches
Sep 12 11:12:13 <TresEquis> Why would the framework push "indexing events" beyond "basic object events"?
Sep 12 11:12:19 <TresEquis> ah, that is a different question
Sep 12 11:12:23 <alecm> expiry/effective events might be nice.
Sep 12 11:13:03 <efge> but yeah I misunderstood sidnei, if he was just talking about event types
Sep 12 11:13:18 <sidnei> scratch that, not sure why i said cataloguing events
Sep 12 11:13:21 <TresEquis> can we separate "creation" from "adding" events? It would mean redoing how the types tool uses the standard factories
Sep 12 11:13:48 <regebro> That could be a good thing to redo anyway.
Sep 12 11:13:50 <TresEquis> efge: are there any indexes which "user search" needs beyond the SearchableText one?
Sep 12 11:13:53 <efge> btw this work will need changing OFS too
Sep 12 11:14:04 <efge> TresEquis: for advanced search yes
Sep 12 11:14:12 <efge> dates, types, metadata, etc
Sep 12 11:14:15 <TresEquis> do any users beyond developers actually use it?
Sep 12 11:14:24 <sebb> yes
Sep 12 11:14:26 <sidnei> yes, object events (add/remove/move/copy) would be better placed on OFS.ObjectManager
Sep 12 11:14:26 <TresEquis> OK
Sep 12 11:14:28 <efge> oh yes, some customers love it
Sep 12 11:14:39 <sebb> "i want all PDFs published before yesterday"
Sep 12 11:14:41 <alecm> If CMFDefault used z3 add forms, then it wouldn't be hard to distinguish the two, otherwise there needs to be some sort of hack like ATs creation flag in place.
Sep 12 11:14:54 <TresEquis> we can't change Zope for this release
Sep 12 11:15:11 <TresEquis> which means we have to supply all that handling in the core containers
Sep 12 11:15:21 <efge> but we can provide suitable overloads in CMFCatalogAware or whatever with the intent of pushing that to Zope
Sep 12 11:15:28 <TresEquis> OK
Sep 12 11:15:40 <TresEquis> another question: do we target Zope 2.8.1? 2.9?
Sep 12 11:16:18 <alecm> TresEquis: Especially with Topic/Smart Folders many catalog indexes can be used by normal users.
Sep 12 11:16:21 <efge> I don't see why not 2.8.1, it has enough features no ?
Sep 12 11:16:37 <TresEquis> do we try to use a subset of the Z3 features which will continue to work on 2.9?
Sep 12 11:16:44 <TresEquis> e.g., we can't use services
Sep 12 11:16:56 <geoffd> zope 2.9 is out in dec, right? if we are looking at a release in that time frame, why not target 2.9?
Sep 12 11:17:23 <TresEquis> geoffd: the downside is that it makes "incremental adoption" harder
Sep 12 11:17:29 <efge> hm weel because we'd want to use it earlier, or test it on real projects
Sep 12 11:17:33 <TresEquis> upside is we don't have to worry about BBB
Sep 12 11:17:51 <efge> at that point I don't know what to target though
Sep 12 11:17:57 <TresEquis> sidnei: what is the "local registry" branch blocked on?
Sep 12 11:18:09 <TresEquis> because *that* might be a deal killer for 2.8.1
Sep 12 11:18:09 <geoffd> so 2.9 will add python 2.4 + z3 security, correct?
Sep 12 11:18:17 <regebro> It's harder to hit a moving target.
Sep 12 11:18:21 <sidnei> TresEquis: i think it was supposed to be merged after five 1.0, but nobody got around reviewing it
Sep 12 11:18:34 <TresEquis> is it based against the 1.0 branch?
Sep 12 11:18:39 <geoffd> regebro: true
Sep 12 11:18:48 <sidnei> TresEquis: yes, was done at the paris sprint
Sep 12 11:18:50 <efge> geoffd: the z3 security is still just a hope...
Sep 12 11:18:52 <TresEquis> Zope 2.9 will include Five 1.1 (or maybe 1.2)?
Sep 12 11:19:10 <regebro> TresEquis: correct.
Sep 12 11:19:12 <geoffd> TresEquis: so no huge changes?
Sep 12 11:19:22 <geoffd> (from 2.8.1)
Sep 12 11:19:28 <TresEquis> we would likely need to update Five to a 1.0.x which included local registries
Sep 12 11:19:40 <TresEquis> maybe Zope 2.8.2?
Sep 12 11:20:07 <regebro> Shouldn't be very big changes. It's the services thingy and and zc.forms, I guess.
Sep 12 11:20:08 <TresEquis> geoffd: I think 2.9 will include the security review to make Python 2.4 supported
Sep 12 11:20:44 <geoffd> ok - i think time based releases will make this all saner -- we can just consistently target current version of zope
Sep 12 11:20:54 <geoffd> and know we won't be more than 6 months behind
Sep 12 11:21:10 <dataflake> so CMF 2.0 -> Zope 2.8.x?
Sep 12 11:21:16 <TresEquis> but we definitely need stuff which is not in Zope right now
Sep 12 11:21:23 <geoffd> k
Sep 12 11:21:29 <dataflake> and CMF 2.1 -> Zope 2.9.x?
Sep 12 11:21:41 <TresEquis> or at least, I think losing local registries will be a deal breaker for some
Sep 12 11:21:56 <TresEquis> I guess we could see how far we get without them
Sep 12 11:22:15 <geoffd> what would be involved in getting them into, say zope 2.8.2 or 2.8.3?
Sep 12 11:22:29 <TresEquis> sidnei: would it be possible to lay down local registries via monkey patch?
Sep 12 11:22:53 <TresEquis> or was it a pervasive change?
Sep 12 11:22:59 <sidnei> TresEquis: that's about all it is *wink*
Sep 12 11:23:31 <sidnei> that's actually local utilities only, not local registries
Sep 12 11:23:50 <regebro> And that is a Five branch, right? Not Zope?
Sep 12 11:23:52 <sidnei> let me get a diff
Sep 12 11:23:52 <TresEquis> we're going to need local adapters and local views
Sep 12 11:23:59 <sidnei> yes, im aware of that
Sep 12 11:24:02 <TresEquis> k
Sep 12 11:24:54 <efge> remind me, the pb is that utilities didn't always get a context information ?
Sep 12 11:24:59 <TresEquis> Hmm, this doesn't work svn+ssh://codespeak.net/svn/z3/Five/branch/paris-localsitemanager-branch
Sep 12 11:25:48 <sidnei> TresEquis: define 'doesn't work'?
Sep 12 11:25:51 <regebro> I think the problem is that there are no sites and sitemanagers, right? So no local utilities.
Sep 12 11:26:22 <TresEquis> I couldn't check that out
Sep 12 11:26:32 <sidnei> TresEquis: https?
Sep 12 11:26:41 <TresEquis> Ah
Sep 12 11:26:45 <sidnei> regebro: i think actually we have a sitemanager and local utility
Sep 12 11:26:47 <TresEquis> forgot they used that
Sep 12 11:27:03 <regebro> sidnei: Yes, in the branch, or?
Sep 12 11:27:09 <sidnei> regebro: branch
Sep 12 11:27:32 <regebro> right. Is there any other problems/hangups for this?
Sep 12 11:28:00 <sidnei> cant remember of any issue
Sep 12 11:28:02 <efge> svn diff -r 9769 http://codespeak.net/svn/z3/Five/branch/paris-local-sitemanager-branch/
Sep 12 11:29:39 <regebro> So, then Zope 2.9 is not needed for this, right? So I'm a bit confused as to why we would need to target Zope 2.9.
Sep 12 11:30:32 <TresEquis> regebro: the Five shipped with Zope 2.8.1 doesn't have any of this support
Sep 12 11:30:32 <sidnei> efge: thanks
Sep 12 11:31:01 <sidnei> would it be reasonable to add add/delete/copy/move events into zope 2.8.x?
Sep 12 11:31:02 <TresEquis> we need local adapters / views / utilities to replace CMF tool lookup
Sep 12 11:31:04 <regebro> TresEquis: Sure, but we can require Five 1.x..
Sep 12 11:31:22 <regebro> For those who want to use it before Z2.9.
Sep 12 11:31:29 <TresEquis> it gets painful, but yes, I think so
Sep 12 11:31:38 <efge> sidnei: they'd be a backport from 2.9, but yes IMHO it would be very useful
Sep 12 11:31:56 <sidnei> i mean, would it be accepted?
Sep 12 11:32:04 <TresEquis> efge: does OFS have those events in 2.9?
Sep 12 11:32:20 <efge> TresEquis: not yet, I was speaking hypothetically
Sep 12 11:32:51 <TresEquis> ah, OK
Sep 12 11:32:55 <efge> what I mean is 2.9 needs them first anyway, and after that anything can be backporterd
Sep 12 11:33:15 <TresEquis> regebro: does the instancehome support allow local products to override those in SOFTWARE_HOME?
Sep 12 11:33:23 <TresEquis> I used to know that
Sep 12 11:33:58 <regebro> TresEquis: Sure.
Sep 12 11:34:15 <regebro> You just install a Five in instance/Products and that's the Five that will be used.
Sep 12 11:34:55 <TresEquis> OK
Sep 12 11:35:21 <TresEquis> does Five 1.1 have the local stuff merged?
Sep 12 11:35:35 <TresEquis> probably not, I would guess
Sep 12 11:35:42 <sidnei> not that i recall, im pretty sure not
Sep 12 11:37:00 <TresEquis> would we extend the 'utility_provider' to be 'component_regsitry', with API for adapters and views?
Sep 12 11:37:22 --> geekwad ([email protected]) has joined #zope-cmf
Sep 12 11:37:57 <TresEquis> Is that Michel?
Sep 12 11:38:22 <sidnei> TresEquis: sounds like it
Sep 12 11:38:24 <efge> given his hostname I'd say yes
Sep 12 11:38:26 <geekwad> This is not Michel, but a different confusingly named individual.
Sep 12 11:38:36 <TresEquis> that would never happen :)
Sep 12 11:38:52 <TresEquis> are you the spider racing Mike Pelletier? ;)
Sep 12 11:39:14 <geekwad> Yes, I am. But I just came for the fun of it.
Sep 12 11:39:21 <TresEquis> lovely
Sep 12 11:40:19 <TresEquis> you and I just missed overlap at Digital Creations, I think
Sep 12 11:41:02 <geekwad> I think we met durring PyCon 8?
Sep 12 11:41:14 <TresEquis> yup, I was interviewing at that point
Sep 12 11:41:43 <TresEquis> in Arlington, VA, right? Snowed in?
Sep 12 11:41:45 <geekwad> You had a very respectable beard and are awesomely well-mannered, IIRC.
Sep 12 11:41:49 <encolpe> A+
Sep 12 11:41:56 <-- encolpe has quit ("Leaving")
Sep 12 11:42:07 <runyaga> so whats next?
Sep 12 11:42:15 <sebb> how about "are there views which will end up being reused across products?"
Sep 12 11:42:17 <runyaga> i turn into a pumpkin in 16 minutes
Sep 12 11:42:27 <sebb> (I was wondering what that meant precisely)
Sep 12 11:42:29 <TresEquis> we need to get a version of Five which supports our needs
Sep 12 11:42:44 <runyaga> TresEquis: so whos responsibility is that? could that happen at the goldegg sprint in 2 weeks?
Sep 12 11:42:59 <sidnei> TresEquis: our needs being local views and adapters?
Sep 12 11:43:03 <TresEquis> runyaga: could be: Faassen will be there
Sep 12 11:43:12 <TresEquis> sidnei: yes, and merging your work
Sep 12 11:43:24 <regebro> I currently can not think of any views used across products.
Sep 12 11:43:29 <runyaga> right.. i think its best for it to happen when t here is a larger group to support and review the work
Sep 12 11:43:39 <TresEquis> either that, or we need to ship a separate product which monkey patches the "core" Five
Sep 12 11:43:44 <runyaga> i cant think of views across products -- possibly folder contents but i would just punt on reuse for now
Sep 12 11:44:01 <sidnei> it can even be completely out of five, it doesn't matter
Sep 12 11:44:18 <TresEquis> sidnei: that might be better than hacking five
Sep 12 11:44:40 <TresEquis> Can we agree that the responsibility for emitting events will move into the views?
Sep 12 11:44:44 <runyaga> yes
Sep 12 11:44:49 <regebro> We'll sync a Five release with CMF 2.0 if needed. No problems.
Sep 12 11:44:50 <runyaga> + 1
Sep 12 11:45:09 <sidnei> TresEquis: that includes add/move/rename/delete events?
Sep 12 11:45:14 <TresEquis> yes
Sep 12 11:45:17 <runyaga> sidnei: yes
Sep 12 11:45:24 <TresEquis> I think those could be emitted by the container views
Sep 12 11:45:27 <runyaga> FolderContentsView could emit 'em
Sep 12 11:45:28 <efge> TresEquis: how can the responsibility move when we don't send events today ?
Sep 12 11:45:54 <runyaga> efge: some ppl may monkeypatch OFS.ObjectManager
Sep 12 11:45:56 <TresEquis> content objects currently send them to "faux" event channels (workflow tool and catalog)
Sep 12 11:46:01 <efge> ah those
Sep 12 11:46:04 <efge> yes
Sep 12 11:46:17 <TresEquis> I want content objects to get much dumber
Sep 12 11:46:23 * runyaga nods
Sep 12 11:46:30 <sidnei> so, cmfcatalogaware would die?
Sep 12 11:46:38 <efge> runyaga: everybody monkey patches OFS.ObjectManager anyway :) so we'd better be careful
Sep 12 11:46:40 <TresEquis> I think so
Sep 12 11:47:09 <runyaga> so i think container views are best.. and we can do that fairly easy
Sep 12 11:47:12 <sidnei> trying to figure out what this means for webdav for example
Sep 12 11:47:14 <runyaga> i would like to chat about events
Sep 12 11:47:22 <TresEquis> OK
Sep 12 11:47:24 <sidnei> as there's no 'views' in webdav, it would move to webdav.Resource
Sep 12 11:47:28 <alecm> Why would we be providing the events with views rather than adapters?
Sep 12 11:48:00 <sidnei> alecm: both views and adapters can fire events, just 'core code' should not do so
Sep 12 11:48:01 <efge> alecm: the views are the component that should decide to send events
Sep 12 11:48:26 <sidnei> maybe adapters shouldnt fire events
Sep 12 11:48:32 * sidnei shuts up
Sep 12 11:48:59 <TresEquis> the webdav PUT handler is basically a view
Sep 12 11:49:05 <efge> alecm: because core code should be core and not deal too much with the framework, but with the content and the application itself
Sep 12 11:49:13 <TresEquis> in fact, we could move that logic there
Sep 12 11:49:20 <efge> OTOH I'm not sure some events don't have their place in the core sometimes...
Sep 12 11:49:29 <sidnei> TresEquis: there == webdav.Resource?
Sep 12 11:49:41 <TresEquis> there == "a view registered for PUT"
Sep 12 11:49:53 <sidnei> TresEquis: what about MOVE and COPY?
Sep 12 11:50:10 <TresEquis> maybe we register those as views, too
Sep 12 11:50:46 <sidnei> doesn't really make sense to make those views in zope2, it's soooooooo much shit to keep track of i doubt anyone can implement a view from scratch and get it right in one year's timeframe *wink*
Sep 12 11:51:22 <TresEquis> webdav.Resource can't do what we want, though
Sep 12 11:51:34 <TresEquis> we'd end up reimplementing almost all of it
Sep 12 11:51:53 <TresEquis> runyaga: what else needs addressing about events?
Sep 12 11:52:01 <runyaga> oh sorry
Sep 12 11:52:03 <sidnei> maybe we factor out existing code into views and have webdav.Resource delegate to views
Sep 12 11:52:17 <TresEquis> in Zope 2.8.x?
Sep 12 11:52:18 <runyaga> one feature i would love tto try to stuff in
Sep 12 11:52:19 <sidnei> i doubt anyone would care to override those views thouhg
Sep 12 11:52:26 <runyaga> is have events be flushed on trnx boundaries
Sep 12 11:52:38 <sidnei> TresEquis: yeah, why not
Sep 12 11:52:40 <runyaga> nuxeo/cps and enfold/plone already have this code
Sep 12 11:52:53 <TresEquis> this is the 'auditlogger' stuff?
Sep 12 11:52:56 <runyaga> mainly just seeing if that would be ok
Sep 12 11:53:09 <runyaga> for us - its auditlogger; i think for cps its so they dont reindex object's more than 1
Sep 12 11:53:27 <alecm> That would be excellent to have IMHO, especially for AT which is terrible in that regard.
Sep 12 11:53:36 <whit> damn tootin
Sep 12 11:53:45 <runyaga> alecm: right
Sep 12 11:53:48 <efge> runyaga: yeah
Sep 12 11:53:52 <TresEquis> does that require hacking the global event service? Or do we register an "aggregating channel"?
Sep 12 11:54:13 <runyaga> i believe currently in our impl its global
Sep 12 11:54:31 <sidnei> it has nothing to do with the event service
Sep 12 11:54:31 <runyaga> efge: you guys have events local to portal instance?
Sep 12 11:54:36 <efge> just have the subscribers push the events to a global queue, that's triggerd at the end of the transaction
Sep 12 11:54:42 <runyaga> ok
Sep 12 11:54:42 <sidnei> it's just a subscriber that is also transaction-aware
Sep 12 11:54:47 <efge> runyaga: yes, the events are sent using a context
Sep 12 11:54:52 <sidnei> yes, same thing here
Sep 12 11:54:58 <efge> and we have a portal_eventservice
Sep 12 11:55:07 <TresEquis> like a 'portal_events' tool?
Sep 12 11:55:08 <TresEquis> ah
Sep 12 11:55:25 <TresEquis> does it function as the local channel for other subscribers, too?
Sep 12 11:55:57 <TresEquis> how does it manage the "coalescing" of similar events?
Sep 12 11:55:58 <efge> in cps it's only used for events, what other subscribers do you have in mind ?
Sep 12 11:56:12 <TresEquis> catalog and workflow tools should be event subscribers
Sep 12 11:56:16 <efge> TresEquis: we leave that to further processing, the event service does not do that
Sep 12 11:56:18 <TresEquis> but only for events in a given site
Sep 12 11:56:35 <TresEquis> do you publish events only at TXN boundary?
Sep 12 11:56:59 <efge> we publish events all the time
Sep 12 11:57:14 <efge> some subscribers delay their processing to txn boundary
Sep 12 11:57:18 <TresEquis> ok
Sep 12 11:57:29 <sidnei> pretty much like 'queue catalog'
Sep 12 11:57:36 <efge> coalescing events is hard though, in general
Sep 12 11:57:43 <sidnei> subscribers queue up events which are processed at txn boundary
Sep 12 11:57:51 <efge> so you want to leave that to specialized code that knows about each event's semantics
Sep 12 11:58:01 <TresEquis> OK
Sep 12 11:58:03 <sidnei> the 'queue' could be smart and coalesce similar events
Sep 12 11:58:07 <alecm> Makes sense to leave it to the subscriber, not all event actions will need this kind of handling. And such a queue may not make sense for every subscriber.
Sep 12 11:58:16 <runyaga> ok
Sep 12 11:58:18 <efge> also, some parts of the framework may not deal well with delayed events
Sep 12 11:58:37 <efge> imagine some security change and a reindexing of allowedRolesAndUsers
Sep 12 11:58:38 <TresEquis> delayed events could be useful for stuff which is "non-transactional"
Sep 12 11:58:46 <TresEquis> like sending mail
Sep 12 11:58:52 <whit> exactly
Sep 12 11:58:58 <efge> if you delay indexing to the end, any catalog search done meanwhile will get different results
Sep 12 11:59:02 <TresEquis> maybe we should just bundle Jens' transactional mailhost
Sep 12 11:59:02 <whit> a sort of defer till x behavior
Sep 12 11:59:31 <TresEquis> efge: within the same request, you mean?
Sep 12 11:59:35 <efge> yes
Sep 12 11:59:50 <efge> the same txn really
Sep 12 11:59:56 <runyaga> ok pumpkln time.. anything else? whats the next steps TresEquis ?
Sep 12 12:00:00 <dataflake> tres: i wouldn't mind
Sep 12 12:00:33 <TresEquis> runyaga: I'll upload log, and modify the roadmap accordingly
Sep 12 12:00:42 <runyaga> TresEquis: thanks
Sep 12 12:00:48 <regebro> The redoing of how typetool uses factories could be of interest as well.
Sep 12 12:00:52 <TresEquis> efge: you had some question about catalog indexing
Sep 12 12:01:07 <TresEquis> regebro: yes, I think we need to move away from the "stock" Z2 factories
Sep 12 12:01:16 <efge> to finish with events: I'd like to have a boolean on the catalog for instance that says "delay indexings"
Sep 12 12:01:47 <efge> TresEquis: not really questions, just some remarks about the different classes of indexes we use really
Sep 12 12:01:53 <TresEquis> OK
Sep 12 12:02:02 <regebro> TresEquis: At least that would open up for making things much more Zope3-ish, by getting rid of factory_type_information. But now we are discussing several issues at once.
Sep 12 12:02:10 <TresEquis> yup
Sep 12 12:02:37 <whit> could you put this on the event, like delay until x happens(another event, txn, etc)
Sep 12 12:03:14 <TresEquis> efge: I think maybe we would have a "delayed" channel, and you could swtich the catalog to subscribe to it when you wanted the delay
Sep 12 12:03:25 <efge> whit I'd say that's too complex for an initial framework, maybe later
Sep 12 12:03:33 <TresEquis> it would just queue up *all* events until TXN boundary
Sep 12 12:04:03 <TresEquis> enfold's logging code might be the basis for the "delayed" channel
Sep 12 12:04:16 <alecm> It might make sense to allow the event emmitter to determine whether the event is delayable (provided the subscriber supports and enables it), as whit suggests.
Sep 12 12:04:17 <efge> hm yeah we still have to "ordering of subscribers" problem somwhere there...
Sep 12 12:04:39 <TresEquis> sidnei: does auditlogger get fired during 'tpc_vote'?
Sep 12 12:05:04 <TresEquis> or do you monkeypatch the publisher to trigger it before the actual commit?
Sep 12 12:05:34 <efge> there's a before commit hook in ZODB now
Sep 12 12:05:44 <TresEquis> in 2.8?
Sep 12 12:05:53 <alecm> yes in 2.8
Sep 12 12:05:54 <TresEquis> cool
Sep 12 12:06:04 <TresEquis> I missed that
Sep 12 12:06:17 <alecm> _before_transaction_commit
Sep 12 12:06:27 <TresEquis> Summarizing:
Sep 12 12:06:57 <TresEquis> - do we add a 'portal_eventservice' tool, which skins / views use as their point of publishing?
Sep 12 12:07:08 <TresEquis> or is the tool where they get subscribed only?
Sep 12 12:07:13 <sidnei> TresEquis: not quite sure it's tpc_vote, let me check
Sep 12 12:07:48 <efge> TresEquis: in the context of Z3 we definitely don't want a portal_eventservice, it's a dead chicken in Z3
Sep 12 12:07:53 <whit> yeah
Sep 12 12:07:56 <sidnei> TresEquis: it's in tpc_finish
Sep 12 12:08:08 <whit> can we start migrating getToolByName to look up utilities
Sep 12 12:08:10 <efge> each tool can provide a subscriber that's context aware and dispatches accordingly
Sep 12 12:08:10 <TresEquis> that's too late for generic event handling
Sep 12 12:08:29 <TresEquis> whit: adapters, mostly
Sep 12 12:08:31 <sidnei> yes, might be too late, but it's just perfect for logging
Sep 12 12:08:45 <TresEquis> sidnei: right
Sep 12 12:08:57 <TresEquis> 'tpc_finish' is not allowed to fail
Sep 12 12:09:22 <TresEquis> I think the before commit hook might be a better point for generic processing
Sep 12 12:09:50 <alecm> doing complex things like catalog indexing post-transaction seems far too dangerous.
Sep 12 12:09:57 <TresEquis> yup
Sep 12 12:10:07 <TresEquis> impossible, even
Sep 12 12:10:19 <efge> TresEquis: I added the hook to ZODB because that's where we needed it :)
Sep 12 12:10:50 <TresEquis> who gets notified? All the "jars" associated with the TXN?
Sep 12 12:10:59 <efge> you register a callable
Sep 12 12:11:08 <efge> with parameters
Sep 12 12:11:12 <efge> and it gets called
Sep 12 12:11:14 <TresEquis> how does it daisy chain?
Sep 12 12:11:42 <efge> they all get called until no more are left, if that's what you ask
Sep 12 12:11:51 <TresEquis> ah, ok
Sep 12 12:12:16 <efge> anguenot wanted to add a priority/ordering mechanism but Jim was of the opinion that ZODB was not the correct layer to do that
Sep 12 12:12:32 <TresEquis> efge: does CPS' portal_eventservice function as the point of publication, the "local subscription point", or both?
Sep 12 12:13:00 <efge> both. But it's pretty old, I'd redesign it differently today
Sep 12 12:13:09 <anguenot> efge: whatever we have our TransactionManager now :)
Sep 12 12:13:41 <anguenot> if you guys wanna check an example
Sep 12 12:13:42 <TresEquis> Would you have events published to the global event "service"?
Sep 12 12:13:51 <anguenot> yup
Sep 12 12:14:13 <efge> TresEquis: with the expectation that some subscribers would redispatch them locally to some tools, yes
Sep 12 12:14:23 <TresEquis> I think each site needs some way to have a filtered event channel
Sep 12 12:14:40 <efge> hm...
Sep 12 12:14:42 <TresEquis> so that tools can subscribe to events which are "local" to that site
Sep 12 12:14:57 <TresEquis> it would be that "redispatch" thing
Sep 12 12:15:30 <TresEquis> I'm not sure how to make subscriptions persistent, however
Sep 12 12:15:44 <efge> I think persistent subscriptions are bad
Sep 12 12:15:51 <TresEquis> I know how we did it in the 'Events' and 'Listeners' products
Sep 12 12:15:52 <efge> we have them and they're a pain
Sep 12 12:16:29 <efge> persistent stuff gets out of sync with the code...
Sep 12 12:16:42 <TresEquis> you can end up with "global" code which knows too much about the persistent store if you go the other route
Sep 12 12:17:42 <efge> we should brainstorm that out at goldegg maybe
Sep 12 12:17:52 <TresEquis> You have to factor stuff such that ZCML is insulated from "local policy" somehow
Sep 12 12:17:53 <TresEquis> OK
Sep 12 12:20:11 <efge> sooo... what else ?
Sep 12 12:20:21 <TresEquis> regebro: do you want to add anything about containerless factories?
Sep 12 12:20:58 <regebro> No, not really, just that it would be nice to not requre factory_type_information...
Sep 12 12:21:12 <TresEquis> oh, speaking of that
Sep 12 12:21:19 <regebro> ...and that more or less requires a refactoring to that fti uses Five.
Sep 12 12:21:31 <TresEquis> what do folks think about splitting out GenericSetup?
Sep 12 12:22:09 <efge> +1 if that makes the development of CMFSetup faster/simpler
Sep 12 12:22:13 <TresEquis> The only downside I can think of is that it becomse a dependency for CMF
Sep 12 12:22:35 <TresEquis> but it does make it possible for non-CMF code to reuse the core
Sep 12 12:22:43 <alecm> +1 from me, especially if actions can become purely local configuration.
Sep 12 12:22:54 <whit> I second that
Sep 12 12:23:04 <TresEquis> I think that having the FTIs go away (in code) is a big win
Sep 12 12:23:32 <TresEquis> dataflake: you pointed out that the types tool UI expects the registry of FTIS
Sep 12 12:23:38 <TresEquis> we will need a way to fix that
Sep 12 12:23:53 <dataflake> tres: yes, the ZMI dropdown when you're in the types tool
Sep 12 12:24:08 <regebro> alecm: What do you think of when you say "local" in "local configuration". :)
Sep 12 12:24:47 <TresEquis> I want the FTI info to become "data" (in setup profiles) rather than code ('factory_type_information' at module scope)
Sep 12 12:24:58 <efge> +10 on that
Sep 12 12:25:04 <TresEquis> I don't know what alecm wants ;)
Sep 12 12:25:05 <regebro> Sounds reasonable, yes.
Sep 12 12:25:21 <dataflake> yes, +100
Sep 12 12:25:30 <TresEquis> Except for the tool UI, I think we could already go there
Sep 12 12:25:31 <alecm> regebro: Product configuration really. Something I can stuff into some XML file in Plone or whatever custom site product and not worry about.
Sep 12 12:25:41 <dataflake> my CMF product did away with them yesterday
Sep 12 12:25:51 <dataflake> products
Sep 12 12:25:53 <sidnei> for me, i think most of the actions make sense as 'global' actions, with an option of turning them 'local'
Sep 12 12:26:15 <TresEquis> sidnei: do you mean overriding them within a given folder in a site?
Sep 12 12:26:24 <sidnei> yes
Sep 12 12:26:26 <alecm> sidnei: yes, I was abusing "local" there.
Sep 12 12:26:28 <TresEquis> or do you mean overriding them in one site within a Zope instance?
Sep 12 12:26:28 <regebro> alecm: OK. CMFonFive currently makes menuItems into actions, but maybe this should be moved to CMFSetup configurations instead?
Sep 12 12:26:31 <efge> the tool add menu will need to consult the registry, but other places in zope do that
Sep 12 12:26:41 <sidnei> well, the later
Sep 12 12:26:46 <sidnei> why not both *wink*
Sep 12 12:27:13 <TresEquis> we have a couple of implementations of "folders-with-local-actions" lying around
Sep 12 12:27:42 <sidnei> my point is, nobody actually customizes 'view' and 'edit' actions for example, unless really really need so
Sep 12 12:28:01 <sidnei> so, having them persisted in tools just make migration forward harder
Sep 12 12:28:17 <TresEquis> What gets customized is the labels
Sep 12 12:28:31 <TresEquis> but I think that CMFSetup can make migration simpler
Sep 12 12:28:40 <efge> overriding things for just one folder/document is really a content problem, quite different
Sep 12 12:28:51 <efge> or metacontent maybe
Sep 12 12:29:06 <TresEquis> dump your tool configuration to a profile, and then find a way to reapply after upgrading software
Sep 12 12:29:19 <TresEquis> efge: agreed
Sep 12 12:29:41 <TresEquis> there are lots of cases where type-based policy may need instance-specific override
Sep 12 12:29:52 <sidnei> wouldn't it be simple to have just *customizations* dumped to a profile, and all actions be global, in zcml or similar?
Sep 12 12:30:05 <efge> sidnei: if you use a framework like plone/cps, indeed you don't change view or edit actions, that's all in the framework's config and doesn't change. but CMFSetup answers that need
Sep 12 12:31:22 <efge> sidnei: there's a tradeoff between simplicity of upgrading the code without changing persistent stuff, and the potential surprised if you upgrade the code and some default change
Sep 12 12:31:40 <alecm> Even if FTIs were no longer required, would they still be allowed (e.g. TTW)? So that people in shared hosting situations could add trivial types in the ZMI.
Sep 12 12:31:56 <efge> suppose a customer relies on the default for some action, and you change that behind his back... I'd rather be fully explicit, and dump/load everything using CMFSetup
Sep 12 12:32:24 <sidnei> i dont' think cmfsetup is the magical solution to that. in fact it will have the exact same issue
Sep 12 12:32:25 <TresEquis> alecm: I think we'll have to allow for that kind of ues
Sep 12 12:32:46 <TresEquis> the hard part of that will be enabling locally-customized templates
Sep 12 12:33:12 <TresEquis> sidnei: at least the setup tool allows you to compare configs
Sep 12 12:33:21 <TresEquis> so you know what has changed
Sep 12 12:33:36 <TresEquis> either in the ZODB or on disk
Sep 12 12:33:48 <sidnei> yeah, i guess that helps
Sep 12 12:34:12 <TresEquis> we might even come up with a way to create "patch" profiles
Sep 12 12:34:16 <efge> to summarize my position: I'm all for removing the ugly fti dicts, but I still want a persistent config in the types tool
Sep 12 12:34:37 <TresEquis> which coupld be applied after an upgrade
Sep 12 12:35:28 <TresEquis> efge: I am also looking to break the dependency on the "old school" factories, which create objects in place
Sep 12 12:35:45 <TresEquis> so that we can separate the "created" from the "added" events, for instance
Sep 12 12:36:07 <TresEquis> that could wait, I guess
Sep 12 12:36:30 <efge> hm that's hard
Sep 12 12:36:38 <regebro> To get rid of ftis we need to refactor the whole shebang anyway so...
Sep 12 12:37:45 <efge> I need to think about remonving ftis, on one hand I'm attracted to it, on the other hand it makes some things much more complex... sidnei I see your point
Sep 12 12:37:48 <TresEquis> regebro: we could dump the gnarly FTI data structures without killing off FactoryTypeInformation (which we need for BBB)
Sep 12 12:38:49 <TresEquis> the data structures just duplicate what is in the CMFSetup profile, any way
Sep 12 12:38:51 <regebro> Well, yes, but I think we would need to reimlement much of FactoryTypeInformation.
Sep 12 12:39:14 <TresEquis> for my "containerless creation", yes
Sep 12 12:39:43 <regebro> Anyway, really. FTI duplicates a lot of what is done in zcml now, and we would rather want to make FTI wrap Zope3 factory type thingies than the otehr way around.
Sep 12 12:40:09 <TresEquis> ZC's Z4I has separate Z3TypeInformation objects
Sep 12 12:40:15 <TresEquis> which handle that case
Sep 12 12:40:28 <regebro> ok, interesting.
Sep 12 12:40:57 <regebro> I tried making those myself, and ended up with a stupid amount of code duplication.
Sep 12 12:41:24 <TresEquis> I'm not saying that those things don't have such a problem ;)
Sep 12 12:42:11 <regebro> But OK; we can see two separate issues:
Sep 12 12:42:13 <regebro> 1. moving fti data to CMFSetup XML.
Sep 12 12:42:33 <regebro> 2. refactoring type information to separate adding and creation.
Sep 12 12:43:28 <TresEquis> the refactoring requires setting up a separate registry of "factories" (separate from the one which drives the ZMI add list)
Sep 12 12:43:59 <TresEquis> we could probably reuse the <content> directive for that ;)
Sep 12 12:44:31 <TresEquis> #1 is an almost pure win, however
Sep 12 12:44:38 <TresEquis> except for the TTI UI
Sep 12 12:44:53 <TresEquis> and the goofy "CMFCore Content" add list entry ;)
Sep 12 12:45:31 <dataflake> are those ZMI entries for "FOO content" even desirable?
Sep 12 12:45:36 <TresEquis> No
Sep 12 12:45:39 <dataflake> i never found them useful
Sep 12 12:45:46 <regebro> And I wouldn't mind being able to use a <content> and <addMenuItem> directive for Zope+Five without CMF either.
Sep 12 12:45:56 <TresEquis> they just encourage users to create broken content objects
Sep 12 12:46:01 <dataflake> yeah, exactly
Sep 12 12:46:24 <TresEquis> I think we can wait for #2, unless somebody gets inspired
Sep 12 12:46:30 <regebro> OK.
Sep 12 12:47:09 <TresEquis> I think we decided to use the same events which Z3 currently declares for creation, adding, moving, deleting, etc.
Sep 12 12:47:30 <TresEquis> we will need events for workflow state changes (likely a before and an after)
Sep 12 12:47:54 <TresEquis> what others? Role changes (e.g., to handle reindexing security)?
Sep 12 12:48:50 <efge> yes security changes need to have their own events
Sep 12 12:49:12 <efge> because they can be special-cased an thus much faster
Sep 12 12:49:46 <efge> we need content change events, I'm not sure what Z3 has at this point
Sep 12 12:50:01 <efge> one question was: what is a content change :)
Sep 12 12:50:23 <TresEquis> I think they were trying for "elegant, general"
Sep 12 12:50:28 <efge> ie some content changes are low level and not user visible, others are visible, some should provoke reindexings, not others...
Sep 12 12:50:33 <TresEquis> I'm willing to live with "simple and stupid"
Sep 12 12:51:09 <efge> I hope that's not a marital remark :)
Sep 12 12:51:18 <TresEquis> heh, nope
Sep 12 12:51:24 <alecm> expiry/effective events (which would need to be triggered by externally) would be a big improvement.
Sep 12 12:51:27 <efge> anyway I've also always been concerned about move events
Sep 12 12:51:43 <efge> I really don't like the fact that move events are dispatched to all subobjects
Sep 12 12:51:47 <efge> the cost may be huge
Sep 12 12:52:14 <TresEquis> we can try for a dumber one
Sep 12 12:52:14 <efge> I'd want a simple basic move event, then if some subscribers wants to recurse in the children let him do it
Sep 12 12:52:27 <TresEquis> and let the catalog optimize, for instance
Sep 12 12:52:41 <efge> this also applies to paste and del of course
Sep 12 12:52:53 <alecm> efge: Many object types may want to know when their path changes though.
Sep 12 12:52:54 <efge> I we can achieve that then yes that'd be great
Sep 12 12:53:04 <TresEquis> paste from copy needs to do something
Sep 12 12:53:15 <efge> alecm: sure but as an added option
Sep 12 12:53:20 <efge> not by default
Sep 12 12:53:21 <TresEquis> alecm: content objects need to get dumber
Sep 12 12:53:51 <TresEquis> especially if the catalog, etc. (and UID -> location stuff) gets smarter about moves
Sep 12 12:54:24 <TresEquis> given adequat UID-location mapping, content can always find out where it is
Sep 12 12:54:27 <alecm> Yes, but these are the views we are talking about. Would we make it so that a move event on a folderish object triggered a recursive reindex on its own?
Sep 12 12:54:50 --- sidnei is now known as sid|fud
Sep 12 12:55:01 <TresEquis> the catalog might be able to fix up the subobjects without even consulting them
Sep 12 12:55:22 <TresEquis> although some indexes might not work
Sep 12 12:55:31 <efge> but it's up to the catalog to decide that
Sep 12 12:55:35 <TresEquis> e.g., if the index is based on an acquired property
Sep 12 12:55:51 <alecm> It's keeping the uid-location mapping in sync that's the problem. Having the catalog do that sort of housekeeping would be nice though.
Sep 12 12:55:54 <efge> then the index would be flagged as "context dependent" or something
Sep 12 12:56:16 <TresEquis> the UID location tool would be a subscriber of the events
Sep 12 12:56:17 <alecm> TresEquis: Can/should the catalog really know if an index comes from an acquired property or not?
Sep 12 12:56:27 <TresEquis> it doesn't *now*
Sep 12 12:56:28 <whit> if the indexing were done by an adapter, the adapter could manage that
Sep 12 12:56:51 <whit> or communicate it to the catalog
Sep 12 12:57:10 <efge> alecm: if it helps optimize the speed of the common case, it'd be worthwhile to be able to instruct the catalog about it
Sep 12 12:57:16 <TresEquis> efge wants to avoid having to consult each object recursively during a move
Sep 12 12:57:33 <alecm> Yes, for some objects it may be acquired otherwise not. An adapter would be useful here.
Sep 12 12:57:36 <whit> that being, "this index is context dependent for this object"
Sep 12 12:57:47 * alecm too, recursive always sucks.
Sep 12 12:57:53 <efge> TresEquis: actually I just wanted to not have an event for each subobject, but I agree with your point
Sep 12 12:58:28 <TresEquis> OK, I'm going to need to bail pretty soon
Sep 12 12:58:47 <TresEquis> I plan to upload transcript and update the roadmap document by tomorrow morning
Sep 12 12:58:48 <whit> cool....one quick thing about cataloguing
Sep 12 12:58:52 <TresEquis> k
Sep 12 12:59:18 <whit> the plonista have been working on some way to indirectly index things by adapter
Sep 12 12:59:25 <TresEquis> right
Sep 12 12:59:46 <TresEquis> adapting the object to an "ICataloguableData" interface, or something?
Sep 12 12:59:50 <whit> we were discussing a name adapter that implements IIndexable for an IFace
Sep 12 13:00:04 <whit> name == index
Sep 12 13:00:08 <whit> or column
Sep 12 13:00:14 <TresEquis> OK
Sep 12 13:00:33 <whit> we also were discussing that an extra directive might really simplify this
Sep 12 13:01:02 <whit> something like
Sep 12 13:01:06 <whit> cmf:indexable for:ISomething attributes='SearchableText path folder_order'
Sep 12 13:01:33 <regebro> Works for me.
Sep 12 13:02:01 <regebro> I've long wanted a way to define in teh product which inexes should exist.
Sep 12 13:02:05 <TresEquis> would that be sugar for a set of named adapters?
Sep 12 13:02:19 <whit> yes
Sep 12 13:02:22 <whit> exactly
Sep 12 13:02:23 <TresEquis> +1, then
Sep 12 13:04:07 <TresEquis> any Parthian shots?
Sep 12 13:04:43 <TresEquis> I'm going to be asking for help from Enfold / Nuxeo on the "deferred events" bit
Sep 12 13:05:11 <TresEquis> and from sidnei / regebro for the "local registry" stuff
Sep 12 13:05:42 <regebro> ok.
Sep 12 13:06:31 <whit> for the index stuff, should we just submit an implementation when we have some code to show?
Sep 12 13:07:29 <TresEquis> can you send me a sample of a directive? I'll include it in the roadmap doc
Sep 12 13:07:33 <TresEquis> [email protected]
Sep 12 13:07:50 <whit> sure!
Sep 12 13:09:08 <TresEquis> Thanks very much to all for participating
Sep 12 13:09:26 <TresEquis> I look forward to seeing some of you in Austria
Sep 12 13:09:38 <whit> cya in vienna TresEquis!
Sep 12 13:09:52 <regebro> See ya!
Sep 12 13:09:57 <efge> bye all
Sep 12 13:10:07 <alecm> Thank you TresEquis
Sep 12 13:16:42 * sid|fud hints those that don't know spanish that 'TresEquis' translates to 'Triple X' :)
Sep 12 13:19:12 <-- geekwad ([email protected]) has left #zope-cmf ("Kopete 0.10 : http://kopete.kde.org")
Sep 12 13:19:13 --- sid|fud is now known as sidnei
Sep 12 13:33:24 <-- alecm (n=alecpm@plone/alecm) has left #zope-cmf ("Konversation terminated!")
Sep 12 13:33:26 <-- dataflake has quit ()
Sep 12 13:42:50 --> RaFromBRC (n=RaFromBR@plone/rafrombrc) has joined #zope-cmf
Sep 12 13:44:03 <-- regebro has quit ("smoking!")
Sep 12 14:01:53 <-- yuppie ([email protected]) has left #zope-cmf