| srichter | J1m: I want to write a small preferences setup where the user can choose the skin s/he wants to use... | 00:01 |
|---|---|---|
| srichter | what would be the best package name? zope.app.zmi? | 00:01 |
| srichter | Later we probably want to expand the preferences | 00:01 |
| *** nathany has left #zope3-dev | 00:06 | |
| *** srichter has quit IRC | 00:14 | |
| *** admp has joined #zope3-dev | 00:24 | |
| *** admp has quit IRC | 00:26 | |
| *** srichter has joined #zope3-dev | 00:36 | |
| *** ChanServ sets mode: +o srichter | 00:38 | |
| tarek_ | srichter: I have written down what would be a global utility in charge of executing code asynchronously, | 00:51 |
| tarek_ | i would like to make a proposal on this | 00:52 |
| *** tonico has quit IRC | 00:52 | |
| srichter | tarek_: ok, do it :-) | 00:53 |
| srichter | or are you not a power user yet and cannot modify proposals? | 00:53 |
| srichter | you shoulod always have a bookmark to: http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/FrontPage | 00:54 |
| tarek_ | ok i have it | 00:54 |
| srichter | click on Proposals and add it there | 00:54 |
| tarek_ | ok i'll do it now | 00:54 |
| *** admp has joined #zope3-dev | 01:00 | |
| tarek_ | oh well, there is a very similar Proposal in progress : TaskSchedule | 01:00 |
| *** admp is now known as admp|sleep | 01:00 | |
| srichter | tarek_: it has not been worked on for a long time (like all proposals) | 01:01 |
| srichter | so if you are willing to do a new proposal and implement it, feel free to change the existing one to your heart's content | 01:02 |
| tarek_ | srichter: ok, it's a bit differen, i will add a new one and make links on it | 01:02 |
| srichter | yep | 01:03 |
| srichter | tarek_: btw, add new proposals to the top | 01:08 |
| tarek_ | ok, i'll move it up | 01:09 |
| tarek_ | I hope it won't look ridiculous, as my knowledge of Z3 is very poor at this time :) | 01:12 |
| srichter | tarek_: the worst that can happen is that people correct your proposal and comment on open issues | 01:13 |
| srichter | I think the tough issue here is transaction handling with the ZODB | 01:13 |
| tarek_ | yes indeed | 01:14 |
| srichter | which is not a Z3-pure issue | 01:14 |
| *** J1m has quit IRC | 01:31 | |
| *** admp|sleep has quit IRC | 01:35 | |
| *** SteveA has quit IRC | 01:39 | |
| *** SteveA has joined #zope3-dev | 01:39 | |
| *** nisha_cgx has joined #zope3-dev | 01:47 | |
| *** FarcePest has quit IRC | 01:55 | |
| *** Arnia has quit IRC | 01:56 | |
| *** tarek_ is now known as tarek_away | 02:12 | |
| *** bradb has quit IRC | 02:25 | |
| projekt01 | srichter, I will look at preferences tomorrow. | 02:37 |
| *** bradb has joined #zope3-dev | 02:54 | |
| srichter | projekt01: ok, I am writing a demo right now | 03:12 |
| *** BjornT has quit IRC | 03:20 | |
| *** eaon has quit IRC | 03:30 | |
| *** bskahan has joined #zope3-dev | 04:27 | |
| *** RaFromBRC is now known as RaFromBRC|afk | 04:36 | |
| *** _projekt01 has joined #zope3-dev | 04:47 | |
| *** projekt01 has quit IRC | 04:47 | |
| *** BjornT has joined #zope3-dev | 04:59 | |
| *** bskahan has quit IRC | 05:12 | |
| *** _projekt01 has left #zope3-dev | 05:30 | |
| *** nisha_cgx has quit IRC | 05:30 | |
| *** `anthony has quit IRC | 05:40 | |
| *** `anthony has joined #zope3-dev | 05:41 | |
| *** RaFromBRC|afk is now known as RaFromBRC | 06:07 | |
| *** `anthony has quit IRC | 06:27 | |
| *** `anthony has joined #zope3-dev | 06:39 | |
| *** RaFromBRC is now known as RaFromBRC|out | 06:46 | |
| *** hazmat has quit IRC | 06:51 | |
| *** th1a has quit IRC | 07:51 | |
| *** admp has joined #zope3-dev | 08:36 | |
| *** BjornT has quit IRC | 09:57 | |
| *** d2m has joined #zope3-dev | 10:33 | |
| *** RaFromBRC|out is now known as RaFromBRC | 10:43 | |
| *** htd has joined #zope3-dev | 11:26 | |
| *** tarek_away has quit IRC | 11:42 | |
| *** tarek_away has joined #zope3-dev | 11:49 | |
| *** mexiKON has joined #zope3-dev | 12:11 | |
| *** gintas has joined #zope3-dev | 12:24 | |
| *** philiKON has quit IRC | 12:34 | |
| *** tarek_away has quit IRC | 13:02 | |
| *** viyyer has joined #zope3-dev | 13:43 | |
| *** projekt01 has joined #zope3-dev | 14:06 | |
| *** gintas has quit IRC | 14:14 | |
| *** htd has left #zope3-dev | 14:25 | |
| *** stub has quit IRC | 14:46 | |
| *** admp has joined #zope3-dev | 14:52 | |
| *** J1m has joined #zope3-dev | 15:04 | |
| *** tarek_ has joined #zope3-dev | 15:15 | |
| *** projekt01 has left #zope3-dev | 15:23 | |
| srichter | good morning everyine | 15:23 |
| J1m | hey | 15:23 |
| tarek_ | does anyone knows where i can find documentation about ZODB transactions ? | 15:24 |
| tarek_ | also, good morning :) | 15:24 |
| srichter | J1m: I got the preferences system done yesterday; I am pretty happy with it; as demo you can change the skin you are using by simply changing the setting :-) | 15:25 |
| srichter | tarek_: I think you do not need to lock the ZODB explicitely; somehow the code should be able to handle ConflictErrors | 15:26 |
| tarek_ | in fact, i get weird errors in the thread | 15:27 |
| tarek_ | so i have tried to do a commit / begin in it but it's not the solution | 15:27 |
| srichter | do you properly start and end the transaction? | 15:27 |
| J1m | tarek_, what is the problem? | 15:28 |
| srichter | mmh, maybe we can reuse some of the publisher framework | 15:28 |
| tarek_ | ok, i am launching a thread from zope that does indexing stuff | 15:29 |
| J1m | why? | 15:29 |
| J1m | why are you launching a thread? | 15:29 |
| tarek_ | the goal is described in the proposal i have made | 15:29 |
| tarek_ | let me get you the url / | 15:29 |
| tarek_ | http://www.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/RunningAsynchronousCode | 15:30 |
| tarek_ | in two words i need to run aysnchronous things | 15:31 |
| J1m | Do you mean, you want, from a web request to start processing that the web request doesn't wait for? | 15:32 |
| tarek_ | yes | 15:32 |
| tarek_ | to give back the hand to the user | 15:33 |
| tarek_ | like zope.app.mail does for sending mails, | 15:33 |
| J1m | I don't know how zope.app.mail works. | 15:34 |
| tarek_ | it's a threaded queue that sends mail asynchronously | 15:34 |
| J1m | so thre is a separate thread that handles the queue? | 15:35 |
| tarek_ | the extra thread is created once and get jobs | 15:35 |
| tarek_ | yes | 15:35 |
| J1m | And app code adds things to the queue, by writing data to a directory? | 15:35 |
| tarek_ | yesµ | 15:35 |
| J1m | This doesn't sound like what you want. | 15:36 |
| tarek_ | not exactly | 15:36 |
| tarek_ | since I want to execute methods | 15:36 |
| tarek_ | but i do want a queue that launches those methods | 15:36 |
| tarek_ | and die after the work is done | 15:37 |
| J1m | why | 15:37 |
| J1m | sounds cmplicated | 15:37 |
| J1m | sounds complicated | 15:37 |
| J1m | Let's get back to the original use case | 15:37 |
| tarek_ | ok, in other words | 15:37 |
| tarek_ | yes | 15:37 |
| tarek_ | the use case : | 15:37 |
| tarek_ | i have a webmail | 15:37 |
| tarek_ | that shows mails | 15:37 |
| *** efge has joined #zope3-dev | 15:38 | |
| tarek_ | when a mail is shown, there's a few things that has to be sent to imap server | 15:38 |
| tarek_ | those thingdoes not interfer with the render | 15:38 |
| tarek_ | but has to be done then | 15:38 |
| tarek_ | one example : | 15:38 |
| tarek_ | setting a flag to "read" | 15:38 |
| efge | yo tarek_ | 15:39 |
| tarek_ | hello efge | 15:39 |
| tarek_ | this lags sometimes, or worse, makes my web request timout | 15:39 |
| tarek_ | if it's async it should be ok | 15:39 |
| tarek_ | but for serialization | 15:39 |
| tarek_ | the best way would be to have a queue per session id | 15:40 |
| J1m | This particular example doesn't need access to ZODB, does it? | 15:40 |
| J1m | why is the "best way to have a queue per session id"? | 15:40 |
| tarek_ | no you are right, but as a matter of fact, it's calling some imap handling utility | 15:40 |
| tarek_ | because one session id = one mailbox | 15:41 |
| J1m | what is a session id? | 15:41 |
| tarek_ | what i call a session id, is a user connection | 15:41 |
| J1m | to imap? | 15:41 |
| tarek_ | to the web app | 15:41 |
| *** projekt01 has joined #zope3-dev | 15:41 | |
| J1m | So having a queue per web session sounds especially complicated | 15:42 |
| J1m | why do you need that? | 15:42 |
| J1m | why a queue? | 15:42 |
| tarek_ | to be sure that all calls to one imap mailbox are serialized | 15:43 |
| *** SteveA has quit IRC | 15:43 | |
| J1m | This keeps getting more and more complicated and now fairly imap specific | 15:43 |
| tarek_ | well | 15:44 |
| tarek_ | there must be more elegant and simpler way to do it for sure :) | 15:45 |
| tarek_ | do you want me to erase that proposal ? | 15:45 |
| J1m | I don't want something in the core to try to solve your specific problem. | 15:46 |
| srichter | no, proposals don't get ereased; the worst would be to document why this proposal was not accepted, reject it and move it to OldProposals | 15:46 |
| J1m | Why do you need to serialize requests to imap? | 15:47 |
| tarek_ | i don't think it's imap specific | 15:47 |
| tarek_ | it's just a web specific thing imho : | 15:47 |
| J1m | You have this weird serialization requirement that seems to be imap specific | 15:47 |
| tarek_ | they can be stuff done to render a page, and work done background | 15:48 |
| J1m | You don't need a queue for that | 15:48 |
| J1m | Why do you need to serialize requests to imap? | 15:48 |
| efge | Some imap operations cannot be reordered | 15:49 |
| tarek_ | here's the two reasons that made me thaught about it : | 15:49 |
| tarek_ | eys | 15:49 |
| tarek_ | 1. orders | 15:49 |
| tarek_ | 2. if there are too much calls there goigne to be threads all over the place | 15:49 |
| J1m | hm | 15:51 |
| tarek_ | the order one is evry imap specific you are right | 15:52 |
| tarek_ | but imho the 2. is not | 15:52 |
| J1m | It's also unclear what the ordering requirement is. | 15:52 |
| *** mexiKON has quit IRC | 15:53 | |
| srichter | J1m: why? what comes in first must be done first. | 15:54 |
| srichter | J1m: what's not clear about that? | 15:54 |
| J1m | How do you decide what comes in first? Especially in a multi-threaded or multi-process (ZEO) application? | 15:55 |
| J1m | Request start time? | 15:55 |
| J1m | Request fincish time? | 15:55 |
| J1m | Transaction cmmit order? | 15:55 |
| tarek_ | it's up to the system | 15:55 |
| J1m | Transaction commit order? | 15:55 |
| J1m | That's not an answer | 15:56 |
| srichter | right | 15:56 |
| tarek_ | i mean, anyone would fit | 15:56 |
| srichter | however, I think we do not need to overthink the problem | 15:56 |
| J1m | If any policy would fit, then I'm skeptical of the ordering requirement | 15:57 |
| srichter | basically we want to ensure that a certain step A is done before B | 15:57 |
| tarek_ | it has to be fixed somewhere within the process | 15:57 |
| J1m | Is it just important that operations performed in a single transaction are ordered? | 15:57 |
| srichter | a single user would always send A before B | 15:57 |
| J1m | srichter, if they are sending them in separate web requests, the order isn't clear | 15:58 |
| srichter | why not? | 15:58 |
| J1m | are we really only talking about operations within the same transaction? | 15:58 |
| srichter | In the UI, the user does first request A then B | 15:58 |
| J1m | Because the browser may send the requests in paralel | 15:58 |
| srichter | that's true, but not practical for a single user | 15:58 |
| J1m | It happens all the time, depending on the app | 15:59 |
| srichter | I cannot delete a mail before I fetched it, for example | 15:59 |
| J1m | why not? | 15:59 |
| srichter | because I do not know I have it in the first place | 15:59 |
| J1m | so, you are saying that the user will view the result of one op before sending another | 16:00 |
| J1m | but we seem to be talking about ops that the user doesn't wait for and thus doesn't see | 16:00 |
| srichter | right | 16:00 |
| tarek_ | yes | 16:00 |
| tarek_ | or see aftewards | 16:01 |
| srichter | :-) good point; so I should think about something else | 16:01 |
| srichter | ahh | 16:01 |
| srichter | let's say a message gets moved to folder X, but then I delete the message from folder X | 16:01 |
| J1m | In that case, it's not so clear what the order is | 16:01 |
| J1m | Are these done in 2 web requests? | 16:02 |
| srichter | yes | 16:02 |
| J1m | Then you are toast | 16:02 |
| tarek_ | let's say : i am looking to my folder, | 16:02 |
| tarek_ | fresh mails there | 16:02 |
| J1m | So stop a second | 16:02 |
| tarek_ | i read them and the thread tells map i have read them | 16:02 |
| tarek_ | next tile i get to the folder the icon "new mail" changed | 16:03 |
| J1m | The only way to make this work is if you commit the request to a queue that is transactional | 16:03 |
| J1m | You don't return from the first request until the op request has been written to a transactional queue | 16:03 |
| tarek_ | would'nt that be the threaded queue ? | 16:04 |
| J1m | I don't know what you mean by a threaded queue | 16:04 |
| tarek_ | a transactinonal queue that is not running in the same thread than the first request | 16:05 |
| J1m | sure | 16:05 |
| tarek_ | that's what i need yeah :) | 16:05 |
| J1m | But it needs to be able to work with multiple processes | 16:05 |
| J1m | There queue needs to be in a transactional store, like ZODB | 16:06 |
| tarek_ | that's the part wich is way over my head | 16:06 |
| J1m | Therefore, the objects put in the queue cannot be simple functions. | 16:06 |
| tarek_ | i've thaught about adapters | 16:06 |
| J1m | This is the sort of problem that the tesk schedule was designed for | 16:07 |
| tarek_ | that could wrap the method somehow | 16:07 |
| J1m | You need objects | 16:07 |
| tarek_ | ok | 16:07 |
| tarek_ | are your talking about the Task ScheduleProposal? | 16:08 |
| J1m | For example, to mark a message read, you create a MessageReadTask which has necessary data | 16:08 |
| J1m | You add the message to the task schedule | 16:08 |
| J1m | (or a task queue) | 16:08 |
| J1m | In fact, forget the task schedule | 16:09 |
| J1m | I would recommend a local task queue utility | 16:10 |
| tarek_ | sounds good | 16:10 |
| J1m | It has to be local because, for now, only local utilities can store data in zodb | 16:11 |
| tarek_ | oh ok | 16:11 |
| J1m | The tricky part is going to be avoiding write conflicts. | 16:11 |
| tarek_ | yes indeed | 16:11 |
| J1m | Yopu would then need to define a separate thread or process to process the queue | 16:12 |
| J1m | You would then need to define a separate thread or process to process the queue | 16:12 |
| J1m | This separate thread or process would have to run continuously, polling and processing the queue | 16:12 |
| J1m | (obviously with sleep when there's nothing to do) | 16:13 |
| tarek_ | the hardest part is the write protection | 16:13 |
| J1m | I guess that write conflicts can be handled using conflict resolution | 16:14 |
| J1m | But it will require some cleverness. | 16:14 |
| tarek_ | and a good load of zodb knowledge :-) | 16:14 |
| J1m | Note that the tasks should be picklable, but not persistent. | 16:15 |
| J1m | You don't want to consume database records for them. | 16:15 |
| tarek_ | ok , right | 16:15 |
| J1m | Not so much zodb knowledge, but you will need a clever conflict resolution algorithm. | 16:15 |
| tarek_ | ok | 16:16 |
| *** SteveA has joined #zope3-dev | 16:17 | |
| J1m | I'm still skeptical that you will get the ordering you want on top of a stateless protocol. | 16:17 |
| J1m | I think people tend to expect too much from HTTP | 16:18 |
| J1m | If people use a web-mail system rather than a real imap client, they should expect less, IMO | 16:18 |
| J1m | HTTP is overused, IMO | 16:18 |
| tarek_ | I agree, but Zope is so powerful, we want to do extensive things with it | 16:19 |
| * tarek_ is not sure of the word "extensive" | 16:19 | |
| J1m | Great, but there are inherent limits in HTTP. Of course, Zope isn't limited to HTTP. | 16:20 |
| tarek_ | do you think it could be interesting to modify the proposal with all this points, or is this more likely to be something out of the proposals ? | 16:20 |
| J1m | I think it's something that should be prototyped as a third-party app. | 16:20 |
| J1m | I'm not clear how generally useful this will be. | 16:20 |
| J1m | It's very specific to the queuing desire. | 16:21 |
| tarek_ | ok | 16:21 |
| J1m | There are much simpler solutions if queuing isn't necessary. | 16:21 |
| J1m | And the price to pay is pretty high. | 16:22 |
| J1m | Managing the queue is a pain | 16:22 |
| J1m | For some apps, the pain may be worth it | 16:22 |
| J1m | Here's an example that illustrates the weakness of HTTP. | 16:22 |
| J1m | The user views their folder. | 16:23 |
| J1m | The see an unread message. | 16:23 |
| J1m | The read the message. | 16:23 |
| J1m | When the message is read, an operation is queued to update imap | 16:23 |
| J1m | The user then decides to view the folder again. | 16:23 |
| J1m | You can't queue the folder display because you need the result to show the user, | 16:24 |
| tarek_ | yup | 16:24 |
| J1m | The queue is backed up for whatever reason and the request to update imap hasn't been processed. | 16:24 |
| *** projekt01 has left #zope3-dev | 16:24 | |
| J1m | so the user sees the folder listing with the message shown as unread. | 16:25 |
| J1m | This is unavoidable because HTTP is stateless. | 16:25 |
| J1m | If a stateful protocol was used, then the second folder display would be held until the read operations was written to the imap server. | 16:26 |
| srichter | Unless you locally already mark the message as read and just send the op to IMAP for preocessing | 16:26 |
| tarek_ | yes that's what i do | 16:26 |
| J1m | well, that's a totally different architecture. | 16:27 |
| tarek_ | it's just a matter of syncing imap with local operations | 16:27 |
| J1m | In that case, why bother with the imap server in the first place | 16:27 |
| J1m | So, you are going to duplicate the state of the imap server on the web server so you have an up to date representation. | 16:27 |
| J1m | And then sync over time? | 16:28 |
| srichter | well, is that not exactely what we try toi do? | 16:28 |
| srichter | we record all the changes and have it sync over time | 16:28 |
| srichter | except that we clear the queue as fast as possible instead of waiting a while | 16:29 |
| J1m | No, we don't simply record the changes, we also keep a local representation of the mailbox. | 16:29 |
| tarek_ | a partial representation | 16:29 |
| J1m | The mailbox folder listing doesn't use imap at all, it uses the local copy | 16:29 |
| J1m | I think it needs to be a full representation. | 16:30 |
| J1m | or pretty full | 16:30 |
| tarek_ | yes but imap keeps bodies and atatched files | 16:30 |
| tarek_ | zodb stores headers infos and flags in my case | 16:30 |
| J1m | If it's not full, then you have to be even more clever about keeping track of changes. | 16:30 |
| tarek_ | bodies and attached file do not change | 16:31 |
| J1m | Essentially, you are building a mozilla mail client into your mail server. | 16:31 |
| J1m | Essentially, you are building an imap mail client into your mail server. | 16:31 |
| tarek_ | 99% of operations on a mailbox can be done without calling an imap server if there is a local copy of folder structure and header infos | 16:33 |
| J1m | why use an imap server at all? | 16:33 |
| tarek_ | to avoid having bodies and attached files | 16:34 |
| efge | and because that's what's already there and what customers want to use | 16:35 |
| J1m | That seems like *lot* of complexity *just* to avoid that, | 16:35 |
| J1m | (Especially given the recent blob work.) | 16:35 |
| efge | any IMAP client keeps a local dumbed down representation of the content on IMAP... | 16:35 |
| srichter | tarek_: are you sure? All ops I can think of require a change on the IMAP server | 16:35 |
| tarek_ | srichter: most of the time you are browsing folder and make searches | 16:36 |
| * J1m is pissed that gnome now overrides my keyboard setup | 16:36 | |
| srichter | J1m: get a real desktop and use KDE :-) | 16:36 |
| * J1m is tempted | 16:37 | |
| srichter | KDE works nicely together with xkb (or however it is called) | 16:37 |
| J1m | I'm not familiar with xkb | 16:37 |
| efge | I just read the past messages and I agree that a Task list stored in ZODB is the way to go for async | 16:37 |
| J1m | I'm using xmodmap | 16:38 |
| tarek_ | efge: yes indeed | 16:38 |
| srichter | anyways, I my CAPS LOCAK works great as TAB | 16:38 |
| J1m | efge, except that, in this case, a straight-ahead queue is probably more apropriate | 16:38 |
| efge | I'm just wondering about what J1m said: "Note that the tasks should be picklable, but not persistent. You don't want to consume database records for them." | 16:38 |
| J1m | They are never mutable so they don't need to subclass Persistent | 16:39 |
| efge | to me that means that whenever something is changed in the queue, everything is re-written, that's a lot of traffic. I'd have done small persistent objects. That also helps with conflict resolution | 16:39 |
| efge | changed = task added or removed | 16:40 |
| efge | srichter: doh, CAPS LOCK should be CTRL not TAB !! :) | 16:40 |
| srichter | that's what I meant | 16:41 |
| srichter | :-) | 16:41 |
| J1m | No, caps lock should be function 35, so I can remap it to something useful. (I already have a control key.) | 16:41 |
| efge | Jim you use emacs without caps-lock as control! must be hard on the little finger... | 16:42 |
| tarek_ | ok thanks for the talk all, it was very interesting | have to run | 16:43 |
| *** tarek_ is now known as tarek_away | 16:43 | |
| efge | J1m: would Z2's QueueCatalog architecture be close to what you're suggesting here ? | 16:45 |
| J1m | I don't think so. | 16:48 |
| J1m | It ios far more specialized. | 16:48 |
| J1m | It is far more specialized. | 16:48 |
| J1m | It's related, of course. | 16:54 |
| J1m | (It's conflict resolution code has someproblems though) | 16:54 |
| J1m | efge, wrt using or not using persistent objects, it would not necessarily affect conflict resolution. | 17:00 |
| efge | J1m: my feeling was that it'd be simpler to add to the queue concurrently with removing something if a system of buckets or the like was used | 17:01 |
| efge | but that's only part of the potential conflicts | 17:01 |
| J1m | buckets of some sort could still be helpful | 17:02 |
| J1m | Those would be persistent. | 17:03 |
| *** bskahan has joined #zope3-dev | 17:16 | |
| *** J1m has quit IRC | 17:18 | |
| *** J1m has joined #zope3-dev | 17:22 | |
| *** kaczordek has joined #zope3-dev | 17:30 | |
| *** kaczordek has quit IRC | 17:33 | |
| *** admp has quit IRC | 17:35 | |
| *** admp has joined #zope3-dev | 17:36 | |
| *** admp has quit IRC | 17:40 | |
| *** bskahan has quit IRC | 17:43 | |
| *** BjornT has joined #zope3-dev | 17:46 | |
| *** gintas has joined #zope3-dev | 17:49 | |
| *** tonico has joined #zope3-dev | 17:51 | |
| *** J1m has quit IRC | 17:56 | |
| *** admp has joined #zope3-dev | 18:01 | |
| *** SteveA has quit IRC | 18:08 | |
| *** SteveA has joined #zope3-dev | 18:22 | |
| *** bskahan has joined #zope3-dev | 18:33 | |
| *** admp has joined #zope3-dev | 18:40 | |
| *** admp has quit IRC | 18:42 | |
| *** bskahan has quit IRC | 18:57 | |
| *** bskahan has joined #zope3-dev | 19:02 | |
| *** admp has joined #zope3-dev | 19:02 | |
| *** tonico has quit IRC | 19:02 | |
| *** admp has quit IRC | 19:35 | |
| *** palmTree has joined #zope3-dev | 19:49 | |
| *** admp has joined #zope3-dev | 19:52 | |
| *** admp has joined #zope3-dev | 20:02 | |
| *** admp has quit IRC | 20:02 | |
| *** projekt01 has joined #zope3-dev | 20:08 | |
| *** tvon has joined #zope3-dev | 20:26 | |
| *** bskahan has quit IRC | 20:35 | |
| *** hazmat has joined #zope3-dev | 21:06 | |
| *** bskahan has joined #zope3-dev | 21:07 | |
| *** philiKON has joined #zope3-dev | 21:19 | |
| *** hazmat has left #zope3-dev | 21:52 | |
| *** tarek_away is now known as tarek | 21:53 | |
| *** RaFromBRC has quit IRC | 21:54 | |
| *** admp has joined #zope3-dev | 22:07 | |
| *** projekt01 has quit IRC | 22:10 | |
| *** palmTree has quit IRC | 22:19 | |
| *** bskahan has quit IRC | 22:20 | |
| *** tarek has quit IRC | 22:26 | |
| *** deo has quit IRC | 22:28 | |
| *** tarek has joined #zope3-dev | 22:34 | |
| *** palmTree has joined #zope3-dev | 22:40 | |
| *** admp has quit IRC | 22:42 | |
| *** projekt01 has joined #zope3-dev | 23:11 | |
| *** tvon has quit IRC | 23:32 | |
Generated by irclog2html.py 2.15.1 by Marius Gedminas - find it at mg.pov.lt!