| *** batlogg has quit IRC | 00:09 | |
| *** ofer has quit IRC | 00:14 | |
| *** MJ has quit IRC | 01:05 | |
| *** rocky is now known as rocky|Zzz | 01:06 | |
| *** timte has quit IRC | 01:25 | |
| *** harobed has quit IRC | 02:22 | |
| *** MJ has joined #zope3-dev | 02:39 | |
| *** MJ is now known as MJ|sleep | 02:39 | |
| *** ktwilight has quit IRC | 03:23 | |
| *** ktwilight has joined #zope3-dev | 03:48 | |
| *** ktwilight has quit IRC | 04:07 | |
| *** ktwilight has joined #zope3-dev | 05:03 | |
| *** oferw has joined #zope3-dev | 05:18 | |
| *** whit has joined #zope3-dev | 05:51 | |
| *** baijum has joined #zope3-dev | 05:59 | |
| *** yota has quit IRC | 06:00 | |
| *** ktwilight has quit IRC | 06:02 | |
| *** stub has joined #zope3-dev | 06:13 | |
| *** whit has quit IRC | 06:21 | |
| *** MiUlEr has joined #zope3-dev | 06:25 | |
| *** ktwilight has joined #zope3-dev | 06:27 | |
| *** ktwilight has quit IRC | 06:37 | |
| *** oferw has quit IRC | 06:42 | |
| *** MiUlEr has left #zope3-dev | 07:17 | |
| *** stu1 has joined #zope3-dev | 08:11 | |
| *** eins has joined #zope3-dev | 08:12 | |
| *** stub has quit IRC | 08:30 | |
| *** jukart has joined #zope3-dev | 08:30 | |
| *** stu1 is now known as stub | 08:34 | |
| *** alecm has quit IRC | 08:40 | |
| *** wrobel has joined #zope3-dev | 08:53 | |
| *** d2m has left #zope3-dev | 08:57 | |
| *** zagy has joined #zope3-dev | 08:59 | |
| *** batlogg has joined #zope3-dev | 09:08 | |
| *** d2m has joined #zope3-dev | 09:11 | |
| *** timte has joined #zope3-dev | 09:19 | |
| *** flox has quit IRC | 09:19 | |
| * philiKON tags his book | 09:25 | |
| d2m | cool | 09:27 |
|---|---|---|
| *** jukart has quit IRC | 09:27 | |
| baijum | philiKON: so, it will be available really soon ? | 09:29 |
| philiKON | i certainly hope so | 09:30 |
| philiKON | hopefully before teh end of this year | 09:30 |
| baijum | prining takes that much time ? | 09:31 |
| baijum | printing | 09:31 |
| philiKON | typesetting, printing, binding, distributing | 09:31 |
| philiKON | can take 2 months | 09:31 |
| philiKON | easily | 09:31 |
| baijum | ok | 09:31 |
| *** romanofski has quit IRC | 09:35 | |
| *** romanofski has joined #zope3-dev | 09:35 | |
| romanofski | moin | 09:36 |
| *** jukart has joined #zope3-dev | 09:40 | |
| *** hdima has joined #zope3-dev | 09:47 | |
| *** MJ|sleep is now known as MJ | 09:59 | |
| *** stub has quit IRC | 10:13 | |
| *** philiKON has quit IRC | 10:16 | |
| *** dobee has joined #zope3-dev | 10:25 | |
| *** flox has joined #zope3-dev | 10:38 | |
| *** jhauser has joined #zope3-dev | 10:41 | |
| *** MJ has quit IRC | 10:52 | |
| *** philiKON has joined #zope3-dev | 10:57 | |
| *** dlk has joined #zope3-dev | 11:03 | |
| *** Aiste has joined #zope3-dev | 11:07 | |
| *** srichter has joined #zope3-dev | 11:19 | |
| *** ChanServ sets mode: +o srichter | 11:19 | |
| *** faassen has joined #zope3-dev | 11:29 | |
| philiKON | hi faassen | 11:30 |
| *** MJ has joined #zope3-dev | 11:33 | |
| *** ignas has joined #zope3-dev | 11:34 | |
| faassen | hey | 11:48 |
| romanofski | o/ | 11:51 |
| *** tonico has joined #zope3-dev | 12:07 | |
| *** ktwilight_ has joined #zope3-dev | 12:11 | |
| *** ktwilight_ has quit IRC | 12:12 | |
| *** flox has quit IRC | 12:14 | |
| *** baijum has quit IRC | 12:16 | |
| *** ktwilight has joined #zope3-dev | 12:16 | |
| *** dlk has left #zope3-dev | 12:17 | |
| *** dlk has joined #zope3-dev | 12:22 | |
| *** jinty has joined #zope3-dev | 12:25 | |
| *** flox has joined #zope3-dev | 12:29 | |
| *** batlogg has quit IRC | 12:56 | |
| *** dunny has quit IRC | 12:58 | |
| *** batlogg has joined #zope3-dev | 12:59 | |
| *** stub has joined #zope3-dev | 13:05 | |
| *** dokai has quit IRC | 13:09 | |
| *** dokai has joined #zope3-dev | 13:10 | |
| *** stub has quit IRC | 13:17 | |
| *** mgedmin has joined #zope3-dev | 13:18 | |
| *** mkerrin has joined #zope3-dev | 13:26 | |
| *** romanofski has quit IRC | 13:33 | |
| *** romanofski has joined #zope3-dev | 13:37 | |
| *** benji has quit IRC | 14:08 | |
| *** jinty has quit IRC | 14:21 | |
| dlk | uh... i messed up. | 14:24 |
| *** batlogg has quit IRC | 14:24 | |
| *** batlogg has joined #zope3-dev | 14:27 | |
| *** alga has joined #zope3-dev | 14:28 | |
| *** tonico has quit IRC | 14:28 | |
| *** tonico has joined #zope3-dev | 14:32 | |
| *** jinty has joined #zope3-dev | 14:41 | |
| *** stub has joined #zope3-dev | 14:48 | |
| *** rocky|Zzz is now known as rocky | 14:50 | |
| *** tonico is now known as tonico|away | 14:59 | |
| *** edgordon has joined #zope3-dev | 15:17 | |
| *** benji has joined #zope3-dev | 15:24 | |
| *** niemeyer has joined #zope3-dev | 15:34 | |
| *** Theuni is now known as zopedev | 15:58 | |
| *** zopedev is now known as theuni | 15:59 | |
| *** tonico|away is now known as tonico | 16:35 | |
| *** tonico is now known as tonico|away | 16:43 | |
| *** tonico|away is now known as tonico | 16:45 | |
| *** whit has joined #zope3-dev | 16:45 | |
| *** eins has quit IRC | 16:48 | |
| faassen | benji: just saw your comment in my weblog. :) | 16:58 |
| benji | :) | 16:58 |
| * philiKON checks faassen's log agian | 16:58 | |
| faassen | benji: I already found his style of discussing things 'interesting' :) | 16:58 |
| benji | faassen: yep, disussing things with jm is always interesting | 16:59 |
| philiKON | http://www.red-bean.com/dav/presentations/Poisonous-people.pdf#search=%22poisonous%20people%20sussman%22 | 17:00 |
| faassen | benji: in the old chinese curse sense. | 17:01 |
| benji | heh :) | 17:01 |
| * dlk sighs | 17:01 | |
| faassen | dlk: is that a sigh of agreement or a sigh of, oh, you people. | 17:02 |
| dlk | the former. | 17:02 |
| dlk | the latter, sorry. | 17:02 |
| faassen | dlk: hm. :) | 17:02 |
| * dlk 's ienglish is not as good as it should be | 17:03 | |
| faassen | dlk: so you don't think he has an interesting style of discussing things? | 17:03 |
| dlk | not any more than you have. | 17:03 |
| faassen | dlk: which uses a lot of implications everywhere. I mean, I had him imply I had an elitist attitude before, and such. | 17:03 |
| dlk | all of you imply stuff all the time | 17:03 |
| benji | hey! is that an implication? :) | 17:04 |
| rocky | haha | 17:04 |
| dlk | its just when someone implies something that you don't agree with that you notice that there has been an implication | 17:04 |
| faassen | yes, that's probably true. | 17:04 |
| dlk | benji: no, its is totally explicit :) | 17:04 |
| dlk | explicit is better than... etc ;) | 17:04 |
| philiKON | i don't have much experience in discussing JMO | 17:04 |
| philiKON | wtih JMO even | 17:04 |
| philiKON | but | 17:04 |
| philiKON | i've had a hard time trying to form a response to his post | 17:05 |
| philiKON | till i read faassen's post | 17:05 |
| philiKON | and then i realized why i had such a hard time | 17:05 |
| faassen | I find him implying things that are very negative or plain untrue more often than I find it with other people. :) | 17:05 |
| philiKON | because he was mkaing implications that triggered reactions in my head | 17:05 |
| philiKON | but i couldn't find definite points in his article to respond to | 17:05 |
| faassen | including people I violently disagree with. | 17:05 |
| philiKON | faassen, yes | 17:05 |
| philiKON | i think faassen has a valid point | 17:05 |
| faassen | and I had that impression before this recent episode. :) | 17:06 |
| philiKON | sure, we're often trying to imply things | 17:06 |
| faassen | but of course I can't prove that. | 17:06 |
| philiKON | but JMO's article is implying LOTS | 17:06 |
| dlk | well, we both like zope a lot, but it is very hard to discuss it's shortcomings when you are mostly discussing the "style" of conversation. | 17:06 |
| faassen | anyway, so I find him rather difficult to communicate with. | 17:06 |
| philiKON | dlk, but where does he actually mention short comings? | 17:06 |
| faassen | dlk: sometimes you have to discuss the style of the conversation. | 17:06 |
| faassen | dlk: he was implying all kinds of shortcomings, and I discussed them, making them explicit. | 17:06 |
| dlk | I must saym that is is very smart to move the focus of jm's blog from what he actually said, to what some perceives that he has implied, and his style of implication | 17:07 |
| faassen | dlk: I think you should carefully reread his blog entry. | 17:07 |
| philiKON | dlk, now you're implying we don't want to talk matters, we just want to argue against him | 17:07 |
| dlk | oh, I have, and we have discussed these issues on several occasion sduring the past years. | 17:07 |
| philiKON | dlk, i think martijn addressed some his points of critique. he also agrees with many | 17:08 |
| dlk | philiKON: yes, that is the impression I have | 17:08 |
| dlk | yes, he and Martin did, Tres did as well. the rest is not. | 17:08 |
| faassen | dlk: I felt he wasn't doing a constructive criticism, but that he was saying things that were plain untrue, in many of the cases. | 17:08 |
| *** gumpa has joined #zope3-dev | 17:09 | |
| faassen | dlk: and he was doing it by implication. | 17:09 |
| faassen | dlk: like, we can learn from the java world not to just check everything under the zope. package. | 17:09 |
| dlk | anyway, some of the issues he raises have been discussed on the zope3 dev list and have been dismissed as non-issues | 17:09 |
| faassen | dlk: that says we do. which we don't, so that's just annoying to say. | 17:09 |
| dlk | I am thinking about api stability here. | 17:09 |
| faassen | dlk: we didn't dismiss them as non-issues in my reading of that discussion. anyway, I agree API stability is important. | 17:09 |
| faassen | dlk: I disagree that the Java world has a great solution. | 17:10 |
| faassen | dlk: he implied we have a massively unstable API, which is untrue. | 17:10 |
| dlk | well, a 3.2 that is toally uncompatible with 3.0 is massive change. | 17:10 |
| faassen | dlk: well, that's a falsehood. :) | 17:11 |
| philiKON | that's just bullshit | 17:11 |
| dlk | it is? | 17:11 |
| philiKON | it is | 17:11 |
| faassen | dlk: Philipp should know, he went through his book and updated the code samples. :) | 17:11 |
| dlk | maybe I misunderstand the messages on the list. Sorry about that. | 17:11 |
| * theuni puts the bullshit into packages and starts selling it | 17:11 | |
| philiKON | yes, it's an anti-hype | 17:11 |
| philiKON | "OMG, all these deprecation warnings. this is hell, you guys are rewriting zope 3 with every release" | 17:11 |
| faassen | I mean, that's not to say we shouldn't aim for API stability and that we were perfect, but actually the project was far more anal about deprecation stuff than I would've been if I had been in charge. :) | 17:12 |
| philiKON | :) | 17:12 |
| philiKON | point is, we actually provide BBB for 2 releases | 17:12 |
| philiKON | not many projects do this | 17:13 |
| philiKON | we try really really hard to provide BBB | 17:13 |
| philiKON | really hard | 17:13 |
| philiKON | nobody acknowledges this | 17:13 |
| philiKON | they see a deprecationwarning and think: OMG, my application breaks | 17:13 |
| philiKON | </rant> | 17:14 |
| faassen | right, perhaps this is in part due to visibility of the API changes. | 17:15 |
| faassen | not so much the APi changes itself, but that API changes are visible. | 17:15 |
| philiKON | dlk, JMO admitted in a comment that most of the implications he made were based on personal mistakes. | 17:15 |
| faassen | by getting deprecation warninsg. | 17:15 |
| faassen | so people go say something about it. | 17:15 |
| faassen | if we just broke the API, I'm not sure what would've happened. | 17:15 |
| philiKON | dlk, so, a very constructive way of criticism would've been to say: i made these mistakes and Zope 3 didn't prevent me from making them... why is what? | 17:15 |
| srichter | benji: this time Martijn started the flame war or is it Jean-Marc? :-) | 17:16 |
| philiKON | then we could look at how to improve zope 3 and its docs to make it easier not to make these mistakes again | 17:16 |
| faassen | dlk: anyway, I understand you're frustrated and I tried very hard to be fair to his message as far as I could be. | 17:16 |
| dlk | but consider: if several people, excluding jm, that as far as I know never has had any problems following the z3 development, on the development list mention that they perceive a problem with the rapid (i their opinion of course) api changes, and they get replies that go along the line "you should change your business model and charge what it costs" or "you should have capacity enough to follow the checkin list", then does that invalidate | 17:16 |
| benji | I blame Jim | 17:16 |
| philiKON | dlk, your line was cut | 17:17 |
| philiKON | "then does that invalidate" | 17:17 |
| faassen | srichter: what flame war? | 17:17 |
| dlk | , then does that invalidate their worries? Are there concerns totally without merit just because the core developers do not have a problem with it? | 17:17 |
| faassen | dlk: clearly these concerns are not without merit. | 17:17 |
| dlk | srichter: no flamewar | 17:17 |
| faassen | dlk: that doesn't mean we all agree on the reaction. | 17:17 |
| faassen | dlk: to these concerns. I mean, if Christian Theune goes and speaks up about it, then that means something. | 17:17 |
| philiKON | dlk, it's not all of us who say "change your business model" | 17:18 |
| srichter | faassen: I see a lot of emotion flying ;-) (I am reacting to Martijn's weblog post comments) | 17:18 |
| philiKON | dlk, i agree that not everyone can develop agianst the trunk | 17:18 |
| philiKON | and that's fine | 17:18 |
| philiKON | we're open to pointers | 17:18 |
| faassen | dlk: but if the reaction is, all APIs should not change anymore, you cannot move modules around anymore. | 17:18 |
| faassen | dlk: then I think that reaction may not be appropriate. | 17:18 |
| faassen | srichter: well, the emotion was caused by the Nuxeo thing and Jean-Marc's blog, I'd say. :) | 17:19 |
| dlk | faassen: yes, but there has to be a middle way in between moving packages around and climing a static neverchaning API | 17:19 |
| faassen | srichter: I reacted to that. I tried to avoid an emotional tone. | 17:19 |
| faassen | dlk: well, we're already pretty good at supporting deprecated APIs and warning people for a significant period of time. | 17:19 |
| faassen | dlk: 2 releases. | 17:19 |
| philiKON | which is more than 1 year nowadays ;) | 17:20 |
| faassen | dlk: and actually a package move is one of the easiest APIs to fix. | 17:20 |
| faassen | dlk: I mean, that's a trivial fix, changing an import, in many cases, unless it deals with persistent data. | 17:20 |
| faassen | dlk: (and we haven't been moving those packages yet) | 17:20 |
| srichter | faassen: I agree; your post reads fairly calm :-) | 17:20 |
| dlk | faassen: I agree with evrything, but precption is not always about whehter or not it is easily fixed technically ornot. | 17:20 |
| srichter | my fingers are itching to say something about the issue, but I will resist, evne though it is so hard :-) | 17:20 |
| faassen | dlk: well, it's been clear to me for a while we need to do something about perception. :) | 17:21 |
| faassen | srichter: say something where? tell us, tell us! :) | 17:21 |
| dlk | it is about trust in the platform; and I do say this because I *really* like zope and I have spent the past 5-6 years fighting for it's existence in my organization. | 17:21 |
| dlk | so, I an not bashing zope - I want it to be successfull. | 17:21 |
| srichter | faassen: my new blog maybe? :-) | 17:21 |
| faassen | dlk: perhaps JMO's tone was a bit annoying also because he says, in Java they have all this fixed, we should learn from them. | 17:21 |
| faassen | dlk: while I think that's not necessarily the case. :) | 17:22 |
| faassen | dlk: the tone would've been better if he said: things I learned about Zope 3 development. | 17:22 |
| srichter | faassen: maybe later this week when I am home and have some time to read all posts carefully; I am just reading your post for now | 17:22 |
| faassen | and then say: th component architecture is not a new religion, API design matters. | 17:22 |
| faassen | and "APIs change a bit too quickly in Zope 3, that worries me, a specification might help, look at Java" | 17:22 |
| faassen | dlk: anyway, the way things were expressed bothered me, and I made it explicit and took him to task. | 17:23 |
| faassen | dlk: and I agree where I do agree. :) | 17:23 |
| dlk | faassen: ok, but it does, and it is worrying. Maybe a look at how the javaworld handles those matters on a "social" level (not how the implent it in code) might be worthwhile? | 17:23 |
| faassen | dlk: as it's too easy to lose perspective in the heat of the argument and attack *all* the points the other person makes. | 17:23 |
| faassen | dlk: well, I don't think an industry consortium creating fat specifications is the social process we want to, or even *can* adopt given our resources. | 17:24 |
| faassen | dlk: that's one of the social processes I've seen in the Java world. it can lead to good things, but it's massive overhead, and it's not guaranteed to lead to good things. :) | 17:25 |
| faassen | dlk: the focus on APis specified carefully is important. | 17:25 |
| dlk | your are talking implementation again . i would like us to abstract over that and look at the mechanisms and evaluate whether they can solve some of our issues in the zope world. | 17:25 |
| faassen | dlk: but here I think Zope 3 is actually on the forefront in the Python world with its explicit interfaces. so I'm not sure how much more we can take. | 17:26 |
| faassen | dlk: huh? implementation in the form of a process, right? | 17:26 |
| dlk | faassen: on the other hand we know thatn not having some of those processes also lead to bad things. | 17:26 |
| faassen | dlk: I mean, I look at the Java world and I see a year-long process to specify JSR-170 in a closed industry consortium, a public review phase, another rewrite and then everybody is adopting it. I don't think that's an appropriate social process. | 17:26 |
| faassen | dlk: what are you concretely proposing? I mean, we could extend our specification process and try to set Python standards, but that's not what you mean, right? | 17:27 |
| dlk | consider the results of the process. We do not have the resources nor the inclination to do it the slow and ugly way. We don't want to., We should look at what lead to the process results. | 17:27 |
| faassen | dlk: a large design document specifying an API. | 17:28 |
| *** philiKON has quit IRC | 17:28 | |
| faassen | dlk: that multiple vendors then can implement. | 17:28 |
| dlk | yes. | 17:28 |
| faassen | dlk: in Zope 3, we have a smaller design process resulting in an interface definition (which is documented) | 17:28 |
| faassen | which multiple parties can then implement, say, the authentication system. | 17:28 |
| faassen | dlk: we could try to push some of those APIs beyond Zope into other Python implementations. | 17:29 |
| faassen | dlk: historically that's been pretty difficult. ew have been trying to adopt things coming out of the community, such as the WSGI API. | 17:29 |
| faassen | dlk: as time progresses, we could perhaps try to document more completely various APIs and try to extract them to make them more independent of our current implementation. | 17:30 |
| faassen | dlk: no concrete candidate comes to mind right now to me. | 17:30 |
| *** philiKON has joined #zope3-dev | 17:31 | |
| dlk | faassen: the whole point of the API is that is independent of the current implementation (unless I misunderstand what you are traying to tell me). So the API should be reasonable static and the implementation might change all the time. | 17:31 |
| faassen | dlk: well, the benefit of having a specified API allows *different* implementation. | 17:33 |
| faassen | like, authentication against a SQL database, LDAP, etc. | 17:33 |
| dlk | pint in case: I have a non-zope api (where we shoudl have used Z3 schemas btw, but we did not have resources to do that at the time). The implementation has changed a lot during the year we have had it. The actual API, method names, modules, etc, has changed very little - it has gronw a few methods. etc. | 17:34 |
| faassen | the benefit of an API, even if not fully specified, in general is also changing implementation. it's a form of abstraction. | 17:34 |
| faassen | dlk: I think possibly you have the wrong impression of the Zope 3 APIs and their changing. | 17:34 |
| faassen | dlk: I mean, Jim rewrote large parts of the component architecture for Zope 3.3. | 17:35 |
| faassen | dlk: and the old APIs still work. | 17:35 |
| faassen | dlk: some of them are *deprecated* now. | 17:35 |
| faassen | dlk: because we have better ways to do things and we want to point people to them. | 17:35 |
| faassen | dlk: but I think it's not accurate to say we're breaking everyhting in Zope 3 all the time. | 17:35 |
| faassen | dlk: and breaking APIs. I think Zope 3 is breaking APIs relatively infrequently compared to many projects. | 17:36 |
| dlk | faassen: it seems that I have. And I am not saying that either, in fact I don't think anyone has said that, at any time. | 17:36 |
| faassen | dlk: well, I realize that. | 17:37 |
| faassen | dlk: it's just important that in a discussion about API instability.. | 17:37 |
| dlk | it has to be possible to discussed perceived shortcomings in zope without people making too far-going implications. | 17:37 |
| faassen | dlk: in the context of Zope 3.. | 17:37 |
| faassen | dlk: we place things in perspective. | 17:37 |
| faassen | dlk: like, if you say: API instability in Zope 3, it's a point I worry about | 17:37 |
| faassen | then I think when I read that: oh, so APIs are unstable in Zope 3, it's a real big problem of Zope 3 compared to other systems. | 17:38 |
| faassen | and that may be or may not be a correct impression. | 17:38 |
| faassen | dlk: yes, of course it's possible to discuss shortcomings. | 17:38 |
| faassen | dlk: I discuss shortcomings from my perspective all the time. I think we type too much ZCML right now. | 17:38 |
| faassen | dlk: I think we have a sucky web presence. :) | 17:39 |
| faassen | dlk: we have a ton of things to improve. | 17:39 |
| dlk | faassen: to be honest it might be a bigger problem than in other systems, simply because we are so dependant on the success of zope3. | 17:39 |
| faassen | dlk: yes, possibly, but we're also taking a lot of care. | 17:39 |
| faassen | dlk: I mean, the Document Library ran on Zope 3.3 while I develope dit for Zope 3.1 | 17:39 |
| faassen | dlk: except for a few fixes I did in the core, as it wasn't finalized yet and some deprecations didn't work correctly. but that's a development issue. | 17:40 |
| faassen | dlk: it spit out a lot of deprecation warnings, but they were easy enough to fix. | 17:40 |
| dlk | in truth, what do I care if the java or PHP world has static interfaces for past N years. I need to cope with the changes that I *precieve* (yes it is a fear that I have) that it will be hard to follow the changes of my beloved development tool, because the core developres make changes and other prominet z3 people raise concerns. | 17:41 |
| faassen | yes, understood. | 17:41 |
| faassen | but you know, if you have that perception. | 17:41 |
| faassen | that can be because a) it's correct | 17:41 |
| faassen | b) it's not entirely correct | 17:41 |
| faassen | and in case of b), I need to do something about it too, and then the only recourse I have is saying, hey, that's not entirely correct. | 17:42 |
| faassen | also taking into account that this evolution will slow down as time progresses. | 17:42 |
| faassen | as clearly a core is stabilizing. | 17:43 |
| *** hdima has quit IRC | 17:43 | |
| dlk | I am sure that neither you nor srichter, etc, have any problems dealing with those changes, even if you are not the originators. But for me, I have trouble keeping pace with the demands of the customers... and then I have to possibly refarin from newer version that may have the features that I need because of a perceived change that may break a lot of things. | 17:43 |
| dlk | or not, but I Do not know that. | 17:43 |
| srichter | dlk: I started my new blog to help guys like you stay uptodate more frequently | 17:44 |
| srichter | I hope that my posts will be technically informing | 17:44 |
| faassen | dlk: I'm not saying I didn't have any problems. :) | 17:44 |
| dlk | as you say, it might not be correct, but I do not know that. It is this element of insecurity that I believe is the problem with rapid API changes (in actuality or as an incorrect perception). It creates the equvalent of FUD. | 17:45 |
| faassen | dlk: it's just that weighing them at the stage of development we're in, I accept them, and I don't think they're too bad. | 17:45 |
| dlk | sure, but then you are impling (no pun intended) that Z3 is not really stable. | 17:45 |
| faassen | dlk: I also think there should be room for API changes. | 17:45 |
| dlk | impling=implying | 17:45 |
| faassen | dlk: the Zope 3 API sometimes changes. | 17:46 |
| faassen | dlk: the original API is supported for a significant period after the changes. | 17:46 |
| faassen | dlk: and is clearly marked with deprecation warnings, which in most cases point you to what to do instead. | 17:46 |
| dlk | or at least, not stable enough to suit the average joe developer that does not follow core development closely | 17:46 |
| faassen | dlk: I think we should be better at keeping developer notes about the changes. | 17:46 |
| faassen | dlk: and this is one of the things I've been cmoplaining about quite a bit. | 17:46 |
| faassen | dlk: I don't think our change log and proposals in the wiki is enough. | 17:46 |
| faassen | dlk: and I think we should keep more extensive notes while making those changes. | 17:47 |
| dlk | faassen: yes, I know you have, and I agree with you. | 17:47 |
| faassen | dlk: informing the developers what to do, and why the changes were thought necessary. | 17:47 |
| faassen | :) | 17:47 |
| faassen | well, that's good. :) | 17:48 |
| dlk | i think it is mostly about creating that warm fuzzy feeling of "yeah, we are changing a lot, but no worries, we'll be there to help" and then giving developers the means of helping themselves. Remove the insecurities. To stop saying "if you followed the checkins list more closely...", because that does not inspire confidence. | 17:49 |
| faassen | dlk: yes, I think developer perception is very important and Zope 3 has traditionally been particularly sucky about managing it. | 17:50 |
| faassen | dlk: that is why among other things we need to improve our website, as thats an important part, though not by far the only part, of developer perception. | 17:50 |
| faassen | dlk: so yeah, that's a very good point you make. | 17:51 |
| *** dobee has quit IRC | 17:52 | |
| faassen | dlk: one of my primary personal concerns. :) | 17:52 |
| dlk | all in all, I think that there needs be some changes that are not very technical in nature. even though I think that a supernice website is not one of the primary issues, I think that we should look back in horror at the times when the main response to user/developer questions was "use the source luke". I know there are excellent books, yes, but a website is in place. At least zope3 should be mentioned as the Next Big Thing In Zope Land on | 17:55 |
| *** Aiste has quit IRC | 17:56 | |
| faassen | dlk: yes, I think mentioning Zope 3 and giving good pointers is a high priority for our website. | 17:56 |
| faassen | dlk: and yes, these are often social changes, not technical changes. | 17:57 |
| dlk | faassen: the website, is that one of the things that "*someone* should start", with out specifying which someone? :) | 17:57 |
| faassen | dlk: no, I'm in charge of the website story. working on zope foundation website now. | 17:57 |
| dlk | ah, ok, excellent news. | 17:57 |
| faassen | dlk: some work is being done on Zope 3 start page too. and we integrated planet.zope.org | 17:57 |
| faassen | dlk: we may also integrate the zopewiki. | 17:57 |
| dlk | cool | 17:57 |
| faassen | dlk: lots of stuff to work through first. | 17:58 |
| faassen | dlk: my role is to find a way through the issues that block us and enable other people to do the work. make decisions where necessary. | 17:58 |
| faassen | dlk: it's one benefit of having a foundation. :) | 17:58 |
| dlk | :) | 17:58 |
| *** natea is now known as natea|afk | 18:00 | |
| benji | faassen: perhaps we could get the person(s) that run http://planetzope.org/ to transition to planet.zope.org | 18:02 |
| faassen | benji: I'm not sure what you mean? | 18:02 |
| faassen | benji: you mean close planetzope.org? | 18:02 |
| benji | or make them synonyms | 18:03 |
| faassen | benji: they're already the same, planetzope.org and planet.zope.org | 18:03 |
| benji | don't look the same to me :) | 18:03 |
| faassen | benji: no, but they have the same content, they get synched. | 18:03 |
| benji | one is better than two :) | 18:03 |
| faassen | benji: I first want planet.zope.org to look prettier. :) | 18:04 |
| d2m | no problem to prettify it | 18:05 |
| faassen | benji: there's your planet guy. | 18:05 |
| faassen | d2m: we'll prettify it with the new layout at some stage. | 18:06 |
| faassen | anyway, it's on my list of things to do. | 18:06 |
| *** dlk has left #zope3-dev | 18:06 | |
| * benji so wants a newer, simpler zope.org | 18:06 | |
| *** regebro has joined #zope3-dev | 18:06 | |
| faassen | me too. | 18:06 |
| faassen | benji: I just started the discussion concerning the technical infrastructure. | 18:06 |
| faassen | benji: how we get it from ZC-run to community run in easy steps. | 18:07 |
| faassen | the problem is the easy steps. :) | 18:07 |
| benji | :) | 18:07 |
| *** alecm has joined #zope3-dev | 18:10 | |
| *** alecm has joined #zope3-dev | 18:11 | |
| *** stub has quit IRC | 18:19 | |
| *** natea|afk is now known as natea | 18:39 | |
| *** oferw has joined #zope3-dev | 18:40 | |
| *** xenru has joined #zope3-dev | 18:40 | |
| *** ignas has quit IRC | 18:42 | |
| faassen | DeprecationWarning: Tools are deprecated and no-longer used. The tool directive will go away in Zope 3.5 | 18:43 |
| faassen | but it doesn't say what I'm supposed to be doing. :) | 18:43 |
| srichter | oops, I think the UI is going away completely | 18:44 |
| faassen | just get rid of the whole registration? | 18:44 |
| faassen | I'm cleaning up ldapadapter. | 18:44 |
| srichter | yeah | 18:44 |
| srichter | that's what I would do | 18:44 |
| faassen | okay, done. :) | 18:44 |
| rocky | sometime within the next week i'm going to be trying to define my first buildout ... zope2, plone, etc ... any pointers on getting started other than reading zc.buildout and topp.buildout code ? :) | 18:45 |
| WebMaven | So, registration only from Python? | 18:45 |
| srichter | rocky: I have jukart I can ask :-) | 18:45 |
| faassen | WebMaven: I'm not sure I understand? | 18:45 |
| faassen | rocky: you can read the zc.buildout documentation? :) | 18:45 |
| *** whit is now known as whit|bano | 18:46 | |
| rocky | faassen: i said "code" :) | 18:46 |
| faassen | rocky: we have some buildouts around that might be interesting, though I dno't claim they're great. | 18:46 |
| faassen | rocky: yes, you said, any pointers on getting started other than reading code. | 18:46 |
| faassen | rocky: so I mentioned the docs. :) | 18:46 |
| rocky | ah ;) | 18:46 |
| WebMaven | faassen: it sounded as though you and srichter were saying that registration would only happen from python code. | 18:46 |
| srichter | rocky: jukart might be able to get you started | 18:47 |
| faassen | WebMaven: I'm not sure what it is all for, so I wasn't saying much. :) | 18:47 |
| faassen | does jukart have a zope 2 buidout? | 18:47 |
| rocky | srichter: what is jukart ? | 18:47 |
| faassen | it'd be nice if we could have a common zope 2 buildout checked into zope.org | 18:47 |
| rocky | or who? | 18:47 |
| faassen | rocky: a person, I'm sure. :) | 18:47 |
| srichter | faassen: no, we are doing Z3 only | 18:47 |
| jukart | I'm jukart, and I only made a buildout for zope 3 | 18:47 |
| faassen | okay, I will adjust to saying that to rocky. | 18:47 |
| srichter | rocky: jukart is Juergen KArtnaller from Lovely Systems | 18:47 |
| rocky | faassen: yeah we need a common zope 2 buildout checked into zope.org imho | 18:47 |
| faassen | rocky: some common infrastructure for ..right. | 18:47 |
| rocky | srichter: gotcha | 18:47 |
| faassen | rocky: anyway, some random buildouts we got | 18:48 |
| faassen | https://infrae.com/svn/zorg.recipe.oooconv/ | 18:48 |
| *** whit|bano is now known as whit | 18:48 | |
| faassen | that is, recipes we got. | 18:48 |
| srichter | WebMaven: no, I like ZCML and designers like it too :-) | 18:48 |
| faassen | https://infrae.com/svn/zorg.recipe.openoffice/ | 18:48 |
| faassen | https://infrae.com/svn/zorg.recipe.twisted/ | 18:48 |
| srichter | WebMaven: you might want to read my block on what we do | 18:48 |
| faassen | he means his blog. :) | 18:48 |
| WebMaven | srichter: block? | 18:48 |
| rocky | faassen: i can see i'm going to need read up on the concept terms a bit more... those look like recipes while i thought a buildout was the act of using those recipes | 18:49 |
| faassen | though that twisted recipe sucks and actually does something quite evil. | 18:49 |
| faassen | so ignore that. | 18:49 |
| faassen | rocky: oh, sure. | 18:49 |
| WebMaven | srichter: is that the new lovley blog? | 18:49 |
| faassen | rocky: but if you want a zope 2 recipe in svn.zope.org.. | 18:49 |
| faassen | rocky: they ARE recipes. | 18:49 |
| faassen | rocky: sorry about the confusion. | 18:49 |
| rocky | gotcha | 18:49 |
| srichter | WebMaven: yeah; I describe a new package with directive there | 18:49 |
| WebMaven | srichter: so, you mean ZCML and Python, but get rid of the TTW registration UI? | 18:50 |
| faassen | rocky: if you want to work on that, then there's some other examples. the best one is that topp one of course. | 18:50 |
| faassen | anyway, actgual buildout .cf files.. | 18:50 |
| srichter | WebMaven: I think we will explore more custom, but very specific and directed ZCML directives in the future | 18:50 |
| rocky | right | 18:50 |
| srichter | to support non-developers | 18:50 |
| faassen | .cfg files.. we got.. | 18:50 |
| faassen | https://infrae.com/svn/buildout/oooconv-dev/trunk/ | 18:50 |
| faassen | and one here.. | 18:50 |
| faassen | https://infrae.com/svn/documentlibrary/trunk/ | 18:50 |
| faassen | the former is a completely separate buildout, not mixed in with the project. | 18:50 |
| faassen | the latter is a buildout (or in fact 2 of them) for documentlibrary. | 18:51 |
| *** ktwilight has quit IRC | 18:51 | |
| srichter | WebMaven: TTW registration is good for testing, but right, I usually do local registration using z3c.baseregistry or via Python code (i.e. z3c.configurator) | 18:51 |
| faassen | I'm just pointing you to all this in the hope it'll help, not that any of this is helping you a lot with zope 2 stuff. | 18:51 |
| rocky | faassen: so your impression of buildout so far is ..... :) | 18:51 |
| srichter | WebMaven: thanks to Jim's fantastic work, all this is really easy now | 18:51 |
| *** ktwilight has joined #zope3-dev | 18:51 | |
| faassen | rocky: pretty positive. | 18:51 |
| WebMaven | OK. | 18:51 |
| rocky | faassen: not too heavyweight for a site deployment ? | 18:51 |
| faassen | rocky: though it's tough writing a good recipe, once you have them you can bring reuse up to a new level. | 18:51 |
| faassen | rocky: no, though if you're a purist and say, you want to build openldap using buildout and python-ldap too.. | 18:52 |
| *** natea is now known as natea|lunch | 18:52 | |
| faassen | rocky: you're going to be stuck. but slowly that infrastructure will grow. | 18:52 |
| faassen | rocky: I don't think it's too heavy-weight. it's nice to have a reproducable and locally-installable way of doing deployment. | 18:52 |
| faassen | rocky: I ran into all kinds of teething problems but Jim's pretty good at fixing them. | 18:52 |
| faassen | in the Zope 2 world, I'm not sure how buildout is going to work ith classic Zope 2 products. | 18:53 |
| faassen | that would take some thinking. | 18:53 |
| rocky | faassen: well, the most common site deployment i do is... 1) install zope2 2) install more recent Five version 3) install plone products 4) install custom 1 or 2 products 5) setup new zope instance with one plone site with custom products installed | 18:53 |
| srichter | I really want to have recipes that store their meta-data in text files, so that others can parse them too | 18:53 |
| faassen | rocky: anyway, I think buildout will help setting up development as well. | 18:53 |
| faassen | rocky: especiall if you use eggs a lot. | 18:53 |
| WebMaven | srichter: You might want to link to the weblog from the lovelysystems homepage... I had to use Google. | 18:54 |
| faassen | rocky: anyway, I don't know how much it is useful right now in Zope 2, but I definitely want to have buildout recipes that let me do that. | 18:54 |
| faassen | rocky: your deployment structure doesn't sound too difficult so I'm not sure whether it's worth it for you, that's up to you. | 18:54 |
| faassen | rocky: I just love the promise that it has in bringing reuse of applications as components in a deployment. | 18:54 |
| faassen | rocky: having buildout and eggs and zope 3 components makes it much more easy to just say, heck, i'll use that library/application too. | 18:55 |
| rocky | faassen: well... the main reasoning for looking at something like buildout for that simple site deployment is the automation factor... i might have to setup that environment 4 or 5 times | 18:55 |
| faassen | rocky: which one was one major reuse blocker. | 18:55 |
| faassen | rocky: anway, overall buildout is pretty nice, I was happily surprised by it. | 18:55 |
| srichter | WebMaven: I am trying to get the blog subscribed to various planets; I hope it will be picked up | 18:56 |
| srichter | WebMaven: ok, I told Jodok to add the link :-) | 18:57 |
| WebMaven | srichter: is there going to be a new edition of your book? | 19:02 |
| srichter | WebMaven: no :-( | 19:03 |
| rocky | faassen: i'll keep all that under advisement... basically i have 1-2 days of paid time i can use to possibly setup buildout ... but it'd be a shame to the project if i spent all that time and ended up with nothing | 19:03 |
| WebMaven | srichter: publisher doesn't want a 2nd Edition? | 19:03 |
| faassen | rocky: understood. | 19:03 |
| srichter | WebMaven: no, it sells far too little for them to be worth it | 19:03 |
| faassen | rocky: I think whether you'll be successful depends on how much topp already does. | 19:04 |
| faassen | rocky: the big unknown in my mind is zope 2 product support. | 19:04 |
| rocky | right | 19:04 |
| WebMaven | srichter: Any chance they will release it under a free documentation or creativecommons license? | 19:05 |
| srichter | WebMaven: and honestly, it does not pay enough for at this point; next time I do a book I will do something like a collection of READMEs but with a coherent story or a book on how to hack Zope 3, much like philiKON started at his EP2006 shootout presentation | 19:05 |
| srichter | WebMaven: I never asked | 19:06 |
| srichter | WebMaven: though I have full permission to do editions and translations as long as it is non-commercial | 19:06 |
| WebMaven | So, a by-nc-sa license would be allowed? | 19:07 |
| *** MJ has quit IRC | 19:08 | |
| srichter | it is already under a CC license | 19:08 |
| WebMaven | Well, sure, but it's noderivs. | 19:08 |
| srichter | WebMaven: right, but that's really just to protect them commercially | 19:09 |
| srichter | I have permission to do non-commercial derivs | 19:09 |
| WebMaven | by-nc-sa wouldn't do that? | 19:09 |
| srichter | I have not looked at the 2.0 licenses and asked them about it | 19:09 |
| WebMaven | Well, think about it. | 19:10 |
| srichter | it will cost me energy and time, which I have to find first :-) | 19:12 |
| WebMaven | OK. | 19:12 |
| srichter | I keep it in mind | 19:12 |
| *** romanofski is now known as rom|aw | 19:21 | |
| *** srichter has quit IRC | 19:23 | |
| *** flox has quit IRC | 19:27 | |
| *** philiKON has joined #zope3-dev | 19:28 | |
| *** xenru has quit IRC | 19:29 | |
| *** oferw has quit IRC | 19:41 | |
| *** RaFromBRC has joined #zope3-dev | 19:48 | |
| *** replicant has joined #zope3-dev | 19:49 | |
| *** jhauser has quit IRC | 19:49 | |
| *** philiKON has quit IRC | 19:51 | |
| WebMaven | faassen: do you know of anyone who has an 'Event' content type for Zope3? | 19:52 |
| *** natea|lunch is now known as natea | 19:56 | |
| faassen | WebMaven: as in calendering? | 20:01 |
| *** M1 has joined #zope3-dev | 20:12 | |
| rocky | the Choice field requires a vocabulary and can't use a source right? | 20:16 |
| *** flox has joined #zope3-dev | 20:19 | |
| *** alga has quit IRC | 20:24 | |
| faassen | rocky: I thought I had it working with sources. | 20:28 |
| faassen | rocky: but I don't recall the details. anyway, out of here. | 20:28 |
| *** alga has joined #zope3-dev | 20:28 | |
| *** faassen has quit IRC | 20:28 | |
| *** batlogg has quit IRC | 20:35 | |
| *** M1 is now known as MJ | 20:38 | |
| *** whit is now known as whit|lunch | 20:41 | |
| *** Aiste has joined #zope3-dev | 20:46 | |
| *** Aiste has quit IRC | 20:47 | |
| *** regebro has quit IRC | 20:48 | |
| *** whit|lunch is now known as whit | 20:48 | |
| *** batlogg has joined #zope3-dev | 20:56 | |
| *** J1m has joined #zope3-dev | 21:01 | |
| *** tonico is now known as tonico|away | 21:04 | |
| SmokeyD | hey all. Is there a function with which I can get the url of a zope object? | 21:04 |
| benji | zope.component.getMultiAdapter((the_object, the_request), name='absolute_url') | 21:06 |
| benji | there might also be a convienience function to do it for you | 21:07 |
| *** M1 has joined #zope3-dev | 21:08 | |
| *** MJ has quit IRC | 21:08 | |
| *** M1 is now known as MJ | 21:08 | |
| SmokeyD | ok, but this is ok as well. Thanks benji | 21:09 |
| *** replicant has quit IRC | 21:11 | |
| mgedmin | there is | 21:11 |
| mgedmin | zope.app.traversing.api.absoluteURL, or something like that | 21:12 |
| mgedmin | it's reexported as zapi.absoluteURL | 21:12 |
| benji | oh, no! not zapi! :) | 21:12 |
| mgedmin | zope.traversing.browser.api.absoluteURL is the canonical place | 21:12 |
| mgedmin | I can never remember it | 21:12 |
| mgedmin | that's why I use ctags ;) | 21:13 |
| SmokeyD | what is wrong with zapi (I guess it's very stupid question, but i'll ask it anyway :) | 21:13 |
| benji | ctags failed me, I mis-remembered it as absolute_url :( | 21:13 |
| benji | SmokeyD: some consider it bad because it re-exposes things that "live" in other places, in other words it creates duplication | 21:14 |
| benji | mgedmin: if you like ctags you'll probably love cscope (if you don't already use it) | 21:15 |
| SmokeyD | ok. From a development point of view that makes sense | 21:15 |
| SmokeyD | but it is so much easier to use the easy to remember classes | 21:15 |
| SmokeyD | :) | 21:15 |
| mgedmin | benji: I always thought cscope was some sort of a proprietary tool only available on SunOS | 21:16 |
| mgedmin | don't ask me why | 21:16 |
| * mgedmin does an apt-get search cscope and finds it | 21:17 | |
| benji | there are some non-open versions of cscope around, but there are open ones too | 21:17 |
| benji | it's kind of a pain, but if you use Vim the integration is nice (once configured to your liking) | 21:18 |
| mgedmin | from the description I do not think cscope will give me much for Python files | 21:18 |
| mgedmin | I use ctags + id-utils for lightning-fast searches of identifier definition and usage | 21:18 |
| benji | it doesn't understand Python _perfectly_, but pretty darn well | 21:18 |
| benji | (there's also a cscope-for-python project out there, but I couldn't get it to work after five minutes of trying) | 21:19 |
| benji | right, cscope gives you the other direction so you can answer questions like: where do I use this symbol? | 21:19 |
| *** alecm has quit IRC | 21:19 | |
| benji | for example say you have a url and want to know what view is associated with it you can do :cs find f foo.html | 21:20 |
| benji | that'll give you the ZCML file, go down a couple of lines to the template= line and press ctrl-/ f and you'll be editing the template | 21:21 |
| mgedmin | ok, that's a win: id-utils only indexes identifiers, so I could search for 'foo' but not 'foo.html' | 21:22 |
| mgedmin | OTOH I have a vim plugin for recursive greps: :Grepall -name '*.zcml' -- foo.html | 21:23 |
| benji | to each his own... that's the Vim credo isn't it? :) | 21:23 |
| *** jinty has quit IRC | 21:25 | |
| mgedmin | anyway, thanks for the pointer, I'll look into it | 21:26 |
| mgedmin | I wish I knew what cscope did back when I worked with C++ | 21:26 |
| mgedmin | I would've tried looking for a free implementation | 21:26 |
| *** replicant has joined #zope3-dev | 21:26 | |
| * mgedmin loved doxygen for its cross-referencing feature | 21:26 | |
| *** mkerrin has quit IRC | 21:34 | |
| *** gumpa has quit IRC | 21:44 | |
| *** gump1 has joined #zope3-dev | 21:44 | |
| *** jinty has joined #zope3-dev | 21:45 | |
| *** regebro has joined #zope3-dev | 21:47 | |
| *** dunny has joined #zope3-dev | 21:51 | |
| *** vbachs has joined #zope3-dev | 21:52 | |
| SmokeyD | hmm. Here I am again. Is there a way to sort the objects returned by values() from a zope.app.container.btree.BTreeContainer instance? | 22:01 |
| SmokeyD | it does not have a sort method | 22:01 |
| benji | if the number of values is short enough, you can do sorted(my_btree.values()) | 22:02 |
| benji | if the number of values is long, there's no general way to do it | 22:02 |
| SmokeyD | around 20 values | 22:03 |
| benji | then "sorted" will work fine | 22:04 |
| benji | as long as the values aren't _huge_ :) | 22:04 |
| *** gump1 is now known as gumpa | 22:19 | |
| *** alecm has joined #zope3-dev | 22:47 | |
| *** dobee has joined #zope3-dev | 22:54 | |
| *** srichter has joined #zope3-dev | 22:56 | |
| *** ChanServ sets mode: +o srichter | 23:03 | |
| *** jukart has quit IRC | 23:08 | |
| *** jukart has joined #zope3-dev | 23:09 | |
| *** dobee has quit IRC | 23:23 | |
| *** jukart has quit IRC | 23:24 | |
| *** vbachs has quit IRC | 23:25 | |
| *** ChrisW_ has joined #zope3-dev | 23:29 | |
| *** mgedmin has quit IRC | 23:34 | |
| *** timte has quit IRC | 23:57 | |
Generated by irclog2html.py 2.15.1 by Marius Gedminas - find it at mg.pov.lt!