*** lurkymclurkleton has joined #zope3-dev | 00:03 | |
*** aaronv has joined #zope3-dev | 00:09 | |
*** gberdyshev has quit IRC | 00:15 | |
*** pcardune has quit IRC | 00:18 | |
*** aaronv has quit IRC | 00:30 | |
*** aaronv has joined #zope3-dev | 00:31 | |
*** fairwinds has quit IRC | 00:32 | |
*** MrTopf has quit IRC | 00:51 | |
*** lurkymclurkleton has quit IRC | 00:57 | |
*** whit has joined #zope3-dev | 00:59 | |
*** junkafarian has joined #zope3-dev | 01:21 | |
*** MrTopf has joined #zope3-dev | 01:53 | |
*** pcardune has joined #zope3-dev | 01:56 | |
*** junkafarian has quit IRC | 02:05 | |
*** greenman has joined #zope3-dev | 02:06 | |
*** greenman has quit IRC | 02:07 | |
*** whit has quit IRC | 02:15 | |
*** whit has joined #zope3-dev | 02:21 | |
*** aaronv has quit IRC | 02:29 | |
*** sm has quit IRC | 02:32 | |
*** fairwinds has joined #zope3-dev | 02:38 | |
*** vipod has quit IRC | 02:40 | |
*** whit has quit IRC | 03:00 | |
*** MrTopf has quit IRC | 03:04 | |
*** b52laptop has quit IRC | 03:08 | |
*** harobed has quit IRC | 03:09 | |
*** yota has quit IRC | 03:39 | |
*** pcardune has quit IRC | 04:28 | |
*** srichter has joined #zope3-dev | 04:44 | |
*** rocky has joined #zope3-dev | 04:45 | |
*** gberdyshev has joined #zope3-dev | 05:09 | |
*** brandon_rhodes has quit IRC | 05:39 | |
*** philiKON has joined #zope3-dev | 05:39 | |
*** dbfrombrc has quit IRC | 06:33 | |
*** pcardune has joined #zope3-dev | 06:36 | |
*** gberdyshev_ has joined #zope3-dev | 06:48 | |
*** gberdyshev has quit IRC | 07:02 | |
*** greenman has joined #zope3-dev | 07:07 | |
*** greenman has quit IRC | 07:33 | |
*** rocky has quit IRC | 07:37 | |
*** rocky has joined #zope3-dev | 07:53 | |
*** pcardune_vm_ has joined #zope3-dev | 07:59 | |
*** pcardune has quit IRC | 08:00 | |
*** pcardune_vm_ has quit IRC | 08:00 | |
*** pcardune has joined #zope3-dev | 08:06 | |
*** rocky has quit IRC | 08:08 | |
*** greenman has joined #zope3-dev | 08:13 | |
*** fairwinds has quit IRC | 08:14 | |
*** greenman has quit IRC | 09:04 | |
*** harobed has joined #zope3-dev | 09:18 | |
*** pcardune has quit IRC | 09:20 | |
*** hexsprite has quit IRC | 09:28 | |
*** harobed has quit IRC | 10:14 | |
*** greenman has joined #zope3-dev | 10:25 | |
*** timte has joined #zope3-dev | 10:38 | |
*** theuni has joined #zope3-dev | 10:43 | |
*** junkafarian has joined #zope3-dev | 10:46 | |
*** georgyberdyshev has joined #zope3-dev | 10:49 | |
*** gberdyshev_ has quit IRC | 10:49 | |
*** theuni has left #zope3-dev | 10:56 | |
*** greenman has quit IRC | 11:04 | |
*** jukart has joined #zope3-dev | 11:12 | |
*** jukart_ has joined #zope3-dev | 11:27 | |
*** jukart has quit IRC | 11:29 | |
*** jukart has joined #zope3-dev | 11:29 | |
*** vipod has joined #zope3-dev | 11:37 | |
*** jukart_ has quit IRC | 11:47 | |
*** mcdonc_ has quit IRC | 11:51 | |
*** mcdonc_ has joined #zope3-dev | 11:51 | |
*** MrTopf has joined #zope3-dev | 11:52 | |
*** yota has joined #zope3-dev | 11:59 | |
*** theuni has joined #zope3-dev | 11:59 | |
*** theuni has quit IRC | 12:16 | |
*** theuni has joined #zope3-dev | 12:16 | |
*** jukart has quit IRC | 12:17 | |
*** b52laptop has joined #zope3-dev | 12:18 | |
*** romanofski has joined #zope3-dev | 12:20 | |
*** dunny has joined #zope3-dev | 12:22 | |
*** sunew has joined #zope3-dev | 12:27 | |
*** norro has joined #zope3-dev | 12:31 | |
*** romanofski has quit IRC | 12:32 | |
*** jukart has joined #zope3-dev | 12:36 | |
*** jukart_ has joined #zope3-dev | 12:38 | |
*** MrTopf has quit IRC | 12:40 | |
*** norro_ has joined #zope3-dev | 12:49 | |
*** theuni has quit IRC | 12:50 | |
*** norro has quit IRC | 12:56 | |
*** norro_ has quit IRC | 12:56 | |
*** jukart has quit IRC | 12:57 | |
*** jukart_ has quit IRC | 12:58 | |
*** MrTopf has joined #zope3-dev | 13:03 | |
*** greenman has joined #zope3-dev | 13:14 | |
*** romanofski has joined #zope3-dev | 13:24 | |
*** acsr has joined #zope3-dev | 13:28 | |
*** junkafarian has quit IRC | 13:37 | |
*** projekt01 has joined #zope3-dev | 13:59 | |
*** vipod has quit IRC | 14:11 | |
*** flox has joined #zope3-dev | 14:17 | |
*** dunny has quit IRC | 14:21 | |
*** MrTopf has quit IRC | 14:26 | |
*** MrTopf has joined #zope3-dev | 14:54 | |
*** MrTopf has quit IRC | 15:20 | |
*** greenman has quit IRC | 15:21 | |
*** MrTopf has joined #zope3-dev | 15:25 | |
*** ccomb1 has joined #zope3-dev | 15:26 | |
*** ccomb has quit IRC | 15:27 | |
*** romanofski has quit IRC | 15:28 | |
*** regebro has joined #zope3-dev | 15:30 | |
*** quodt has joined #zope3-dev | 15:32 | |
Pan_ | can i access to zodb without zope? | 15:33 |
---|---|---|
*** MrTopf has quit IRC | 15:38 | |
ccomb1 | Pan_ yes the zodb is independant from zope | 15:38 |
Pan_ | cool! i want to check if some of my objects 'expired' in my system and delete them | 15:40 |
Pan_ | how i could do that? with crontab script accessing to zodb? | 15:40 |
*** fairwinds has joined #zope3-dev | 15:45 | |
ccomb1 | Pan_ why not, but there is a package to schedule this kind of actions inside zope (don't remember) | 15:49 |
philiKON | not in z3 | 15:50 |
ccomb1 | ah, bad | 15:50 |
Pan_ | hm. | 15:51 |
Pan_ | so how can i solve my problem :/ ? | 15:51 |
ccomb1 | Pan_ by calling an url poiting to a view that performs such an action ? | 15:54 |
ccomb1 | from a cron job | 15:54 |
Pan_ | ccomb1! | 15:55 |
Pan_ | excellent idea! :) | 15:55 |
Pan_ | i didnt think about that. thanks. | 15:56 |
Pan_ | :) | 15:56 |
*** sunew has quit IRC | 15:58 | |
*** ccomb1 is now known as ccomb | 16:19 | |
*** ccomb has quit IRC | 16:20 | |
*** ccomb has joined #zope3-dev | 16:20 | |
*** ccomb has quit IRC | 16:25 | |
*** ccomb has joined #zope3-dev | 16:27 | |
*** quodt has quit IRC | 16:29 | |
*** Theuni has joined #zope3-dev | 16:41 | |
*** jukart has joined #zope3-dev | 16:44 | |
*** ccomb has quit IRC | 16:45 | |
*** jodok has joined #zope3-dev | 16:45 | |
*** gberdyshev_ has joined #zope3-dev | 16:50 | |
*** jukart has quit IRC | 16:51 | |
*** jukart has joined #zope3-dev | 16:54 | |
*** georgyberdyshev has quit IRC | 17:04 | |
*** jhauser has joined #zope3-dev | 17:13 | |
*** afd_ has joined #zope3-dev | 17:15 | |
*** gberdyshev_ has quit IRC | 17:18 | |
*** regebro has left #zope3-dev | 17:41 | |
*** aclark is now known as aclark|away | 17:58 | |
*** jodok has quit IRC | 18:00 | |
*** projekt01 has quit IRC | 18:07 | |
*** elro has joined #zope3-dev | 18:08 | |
*** andres_f has quit IRC | 18:11 | |
*** srichter has quit IRC | 18:11 | |
*** andres_f has joined #zope3-dev | 18:11 | |
*** jhauser has quit IRC | 18:14 | |
*** philiKON has quit IRC | 18:30 | |
*** philiKON has joined #zope3-dev | 18:31 | |
*** jodok has joined #zope3-dev | 18:32 | |
*** regebro has joined #zope3-dev | 18:38 | |
*** flox has quit IRC | 18:43 | |
*** MrTopf has joined #zope3-dev | 18:44 | |
*** harobed has joined #zope3-dev | 18:47 | |
*** jhauser has joined #zope3-dev | 18:58 | |
*** norro has joined #zope3-dev | 19:06 | |
*** philiKON has quit IRC | 19:08 | |
*** norro has quit IRC | 19:16 | |
*** norro has joined #zope3-dev | 19:16 | |
*** mcdonc_ has quit IRC | 19:17 | |
*** mcdonc has joined #zope3-dev | 19:17 | |
MrTopf | Is there some list which versions of which packages make up e.g. Zope 3.3? | 19:19 |
MrTopf | or are those in sync with the Zope version? | 19:19 |
mcdonc | MrTopf: I think the "KGS" knows | 19:20 |
MrTopf | where do I find it? :) | 19:20 |
mcdonc | or not | 19:20 |
mcdonc | i dont see a way to get at 3.3 | 19:20 |
MrTopf | I have some problems mixing in a package which needs the ZCA with Plone | 19:21 |
MrTopf | and I would like to try to pin the version numbers to those used in the Zope2 version used | 19:21 |
MrTopf | because right now I have conflicts as the Zope2 stuff is not installed as eggs | 19:21 |
mcdonc | looks like the kgs started at 3.4... http://download.zope.org/zope3.4/intro.html | 19:21 |
MrTopf | too bad | 19:21 |
mcdonc | but i'm sure it's in SVN | 19:21 |
mcdonc | http://svn.zope.org/Zope3/tags/ | 19:22 |
afd_ | MrTopf: do a checkout on the 3.3 tag and look at svn:externals, they're probably tied o other tags as well | 19:22 |
MrTopf | ok, thanks, will have a look | 19:22 |
mcdonc | it's likely that you may need to roll your own eggs for the offending packages | 19:23 |
mcdonc | because i dont think 3.3 was eggified | 19:23 |
*** timte_ has joined #zope3-dev | 19:23 | |
*** lurkymclurkleton has joined #zope3-dev | 19:24 | |
*** lurkymclurkleton has quit IRC | 19:25 | |
MrTopf | I slowly come to the conclusion that the rest of the guys around this project have been right in saying that too many external dependencies are not really good.. :/ | 19:26 |
mcdonc | that's the zope2 and django way indeed | 19:28 |
MrTopf | I will now try to remove the requirements from the buildout and setup.py manually | 19:29 |
MrTopf | well, so far having introduced buildout for this project has not made many people happy because of several problems which occured to people | 19:29 |
MrTopf | now with also introducing virtualenv I hope they are fixed though | 19:30 |
MrTopf | I just wonder if grokcore.component will now require all these packages again.. probably | 19:30 |
mcdonc | the "right" way to make repeatable installs with eggs (IMO) is to use your own index | 19:30 |
*** vimes656 has joined #zope3-dev | 19:30 | |
MrTopf | well, in one instance some wrong version of an egg which already was installed globally has been used all the time | 19:31 |
mcdonc | Well, just for reference, further gotchas await here... http://plope.com/Members/chrism/distribution_links_considered_harmful | 19:31 |
MrTopf | can I switch off the automatic resolve of requirements for one egg somehow? | 19:31 |
MrTopf | I think I read this | 19:32 |
mcdonc | the right thing to do is this: make a directory full of the eggs you want, get the makeindex.sh from that page, run it against the eggs, publish the resulting "index" directory (and its parent) on the web as an index | 19:32 |
mcdonc | then use that index in the buildout.cfg | 19:33 |
MrTopf | well, that does not yet help me in this particular case though ;-) | 19:33 |
MrTopf | but I will definitely set this up for general use | 19:33 |
MrTopf | thanks | 19:33 |
mcdonc | if people are becoming untrusting of your buildout, it's the only way to make sure it "always works" (along with virtualenv) | 19:34 |
MrTopf | would be nice if virtualenv would be included in buildout | 19:35 |
MrTopf | I tried to write some different bootstrap.py which does that but so far it's not working | 19:36 |
MrTopf | for now I would need a way though to prevent grokcore.component from installing it's dependencies in the hope that the stuff in Zope2 is sufficient | 19:36 |
MrTopf | and btw, so far nobody trusts buildout anymore ;-) | 19:37 |
mcdonc | yeah. unfortunately you need to stomp on it in several vectors to make builds reliable. | 19:37 |
mcdonc | i write these sorts of instructions for customers: | 19:38 |
mcdonc | 1. install setuptools | 19:38 |
mcdonc | 2. install virtualenv | 19:38 |
mcdonc | 3. create a virtualenv | 19:38 |
mcdonc | 4. check out the buildout *into* the virtualenv | 19:38 |
mcdonc | run bin/python bootstrap.py | 19:39 |
mcdonc | ... and so on | 19:39 |
MrTopf | Here are my instructions which basically do that: | 19:39 |
MrTopf | https://wiki.secondlife.com/wiki/Pyogp/Client_Lib/The_Development_Sandbox | 19:39 |
MrTopf | plus I wrote a bootstrap.py which includes a development version of setuptools | 19:39 |
MrTopf | because of the svn 1.5 problem | 19:39 |
afd_ | mcdonc: wouldn't it be better to install zc.buildout with the easy_install from the virtualenv? Is there a connection made between buildout and virtualenv if they function separately (even if inside the same folder)? | 19:40 |
*** timte has quit IRC | 19:40 | |
afd_ | to tell the truth, I haven't tried this yet | 19:40 |
mcdonc | afd_: my buildouts seem to always be checkouts | 19:40 |
mcdonc | but that's not a bad idea either | 19:40 |
afd_ | based on bootstrap.py? | 19:41 |
mcdonc | yeah | 19:41 |
afd_ | oh, ok then | 19:41 |
MrTopf | so, fake_eggs is now recommended to me | 19:41 |
mcdonc | lord | 19:41 |
*** norro has quit IRC | 19:42 | |
MrTopf | actually I just wanted to quickly create some devel sandbox ;-) | 19:42 |
afd_ | also, I thought buildout worked to achieve the main functions of virtualenv... it's odd that it needs to be installed like that to really separate yourself from system packages... | 19:42 |
MrTopf | afd_: well, it would be cool if it's possible to tell buildout as well to not use system packages.. but in one case it found the zope.interface 3.3.0 egg inside the Mac OSX python installation and used this instead | 19:43 |
mcdonc | afd_: indeed | 19:43 |
*** jodok has quit IRC | 19:44 | |
MrTopf | it even put the path to those site-packages into all the scripts | 19:44 |
mcdonc | MrTopf: which version of zope.interface do you need? | 19:44 |
MrTopf | I don't care I think as I only use the basics in that package | 19:44 |
mcdonc | which package is getting you now? | 19:44 |
MrTopf | but in this case zope.component was already in some newer form there and this led to a problem with OverflowError or somesuch | 19:44 |
MrTopf | but this was solved with virtualenv and setting up the buildout from scratch | 19:45 |
MrTopf | it's this package: http://svn.secondlife.com/svn/linden/projects/2008/pyogp/pyogp.lib.base/trunk/ mixed with a recent plone buildout | 19:45 |
MrTopf | I now set the zope.interface version to 3.3.0 in the buildout.cfg and hope it works | 19:45 |
MrTopf | nope :) | 19:46 |
MrTopf | fake eggs then | 19:46 |
mcdonc | *cough* ..(private index) | 19:46 |
MrTopf | what does a private index bring me? | 19:48 |
mcdonc | repoze.plone has everything eggified but it also suffers from some of this (the same package in multiple distributions)... it's a symptom that we need to repackage i'm afraid | 19:48 |
MrTopf | I don't know the version of the packages I need for it to work. It needs to match what's in Zope 2.10.6 | 19:49 |
mcdonc | MrTopf: it will either work or it wont, and it will work the same every time if it does... if some package depends on a non-version-pinned dependency, by default it will go to pypi and get whatever the last person happened to upload | 19:49 |
mcdonc | where by "by default" i mean without a private index | 19:50 |
mcdonc | so while it might happen to work today | 19:50 |
MrTopf | I know. But I don't know which egg I should put into my index for zope.component and zope.interface | 19:50 |
mcdonc | it might not tomorrow | 19:50 |
MrTopf | I will definitely try out my personal index | 19:50 |
MrTopf | but here it's more Zope2 which is the probem | 19:50 |
MrTopf | problem | 19:50 |
mcdonc | well lets see what it wants... | 19:51 |
mcdonc | 3.3.2 | 19:52 |
mcdonc | i can roll a 3.3.2 egg for you if you'd like | 19:52 |
MrTopf | 3.3.2 of what? zope.interfaces? | 19:53 |
mcdonc | zope.component | 19:54 |
*** mcdonc_ has joined #zope3-dev | 19:54 | |
*** mcdonc has quit IRC | 19:54 | |
MrTopf | how did you find that out? | 19:54 |
mcdonc_ | by running "svn propedit svn:externals ." in the lib/python/zope directory of a checkout of the 2.10 branch | 19:55 |
MrTopf | ah, ok | 19:55 |
MrTopf | then I guess I can also make my own eggs from that for my own index :) | 19:56 |
MrTopf | I am nevertheless trying out fake eggs now | 19:56 |
mcdonc_ | fake eggs might be easier | 19:56 |
MrTopf | esp. as I would like to start developing and stop configuration ;-) | 19:57 |
MrTopf | but I will keep this in mind and setup a individual index nevertheless, seems not to be that hard | 19:57 |
mcdonc_ | it appears that no one bothered to tag 3.3.2 in any z3 "satellite" package | 19:57 |
MrTopf | just need to figure out where to host it | 19:57 |
mcdonc_ | and why would you? it's only the most used version. | 19:57 |
mcdonc_ | builds are a pain but they are extremely important... i spend a lot of time getting them right, and it tends to pay off | 19:58 |
MrTopf | I know, usually they also worked quite well for me.. just now it happened that many people had problems here and they also blame ZCA for it because dependencies is what makes you need buildout | 20:00 |
mcdonc_ | well, they probably should in some sense, because the dependency graph of most z3 eggs is fucked | 20:00 |
mcdonc_ | zope.interface and zope.component arent too bad tho | 20:01 |
MrTopf | I guess also buildout could be made a little more reliable e.g. by adding support for not using site-packages | 20:01 |
MrTopf | well. if you include zc.recipe.testrunner you load 10 eggs with it though | 20:01 |
MrTopf | and grokcore.component also adds some | 20:01 |
MrTopf | at some point it might also be nice to see some dependency graph | 20:02 |
mcdonc_ | buildout is also fucked ;-) you might be better off setting up either a meta-egg with version pins or a private index and using easy_install | 20:02 |
MrTopf | I simply ship tarballs ;-) | 20:02 |
MrTopf | because when you add windows to the mix.... | 20:02 |
mcdonc_ | kinda hard when there's C stuff | 20:02 |
MrTopf | well, several tarballs then | 20:03 |
MrTopf | ok, so fake eggs worked | 20:03 |
mcdonc_ | woo hoo! | 20:03 |
MrTopf | I wonder if this should be in such a buildout per default | 20:03 |
MrTopf | as Hanno said that they answered this question on the list many times | 20:03 |
MrTopf | makes sense to fix it then ;-) | 20:03 |
mcdonc_ | is this a plone build? | 20:04 |
MrTopf | the ZopeSkel plone3_buildout | 20:05 |
mcdonc_ | just curious, why are you using plone for this project? | 20:06 |
mcdonc_ | it doesnt look like it has extreme ui requirements | 20:07 |
MrTopf | well, I want to use Plone as an example of how you can add an AgentDomain to your web site | 20:08 |
MrTopf | so how to basically turn your plone site into a provider for Agents which can be used in OGP based virtual worlds | 20:08 |
mcdonc_ | plone seems awful heavy for that | 20:08 |
MrTopf | sure, but there I know how to create views and all that why when using e.g. grok I will be more lost in finding out how to do certain things with grok/zope3 | 20:09 |
MrTopf | while I also want to do this at some point as another example right now I wanted to be on the safe side to concentrate on the actual problem | 20:09 |
MrTopf | turned out though that this did not work as expected ;-) | 20:09 |
mcdonc_ | well, i'll be self serving... http://static.repoze.org/bfgdocs/index.html | 20:09 |
MrTopf | I read about this and it looks promising but for me right now it would be again learning a new framework | 20:10 |
mcdonc_ | this is a zopeish thing that is 1/16 as complicated as zope3 and 1/1000 as complicated as plone | 20:10 |
mcdonc_ | you could have learned it in the time you spent unfucking the dependencies | 20:11 |
MrTopf | is there some user management included? | 20:11 |
MrTopf | well, this wasn't to be expected ;-) | 20:11 |
MrTopf | and as a side effect I now learned about fake eggs which might be useful in the future anyway because we do quite a bit of Plone | 20:11 |
MrTopf | so once I have this finished I will look at bfg :) | 20:11 |
MrTopf | but expect some questions :) | 20:12 |
mcdonc_ | ok, i know how it is... | 20:12 |
mcdonc_ | you stick with what you know | 20:12 |
MrTopf | well, I am open to try out something new | 20:12 |
MrTopf | the thing just it: When I tried out grok a while ago I directly ran into the problem that I wanted to create some user and usermanagement wasn't included in grok.. So I needed to do it the Zope3 way but didn't have philikons book with me and there is not too much findable online | 20:13 |
MrTopf | but as I see bfg seems to have good documentation :) | 20:14 |
mcdonc_ | MrTopf: bfg relies on middleware for authentication (repoze.who, typically, or just an apache REMOTE_USER) | 20:14 |
mcdonc_ | it does not have ui for user management | 20:14 |
mcdonc_ | (it doesnt even have a User class) | 20:14 |
MrTopf | well, then I would need to implement that.. | 20:14 |
mcdonc_ | yes. | 20:15 |
MrTopf | but I guess it will be easier than then the zope3 way or at least more approachable | 20:15 |
MrTopf | as z3 usually is easy as long as you know how you have to do stuff | 20:15 |
mcdonc_ | theres no magic in it | 20:15 |
MrTopf | that's why it was also ok to use django because in the case of a problem I still could read the code and knew what was going on | 20:15 |
mcdonc_ | you'd have to write a view that looked in your user database and let you tweak stuff | 20:16 |
MrTopf | although they tried to obfuscate it with metaclasses | 20:16 |
mcdonc_ | yeah.. bfg is modeled more after django from a dev perspective than it is zope. | 20:16 |
MrTopf | I guess I simply need some db table which has some user info then | 20:16 |
mcdonc_ | right | 20:16 |
MrTopf | ok, sounds easy | 20:16 |
MrTopf | well, I will have a look at it :) | 20:16 |
MrTopf | but for now I will implement that agent domain stuff for Plone and as a result I will make progress on pyogp.lib.agentdomain which should be reusable then | 20:17 |
MrTopf | actually Plone only provides the hooks for the lib | 20:17 |
mcdonc_ | seems like maybe you should develop that lib independent from plone (or zope or anything) | 20:17 |
MrTopf | that's the plan | 20:18 |
MrTopf | I just use Plone as an example of how to use it and develop the structure according to what I need there | 20:18 |
MrTopf | so the views are mostly delegating to that lib | 20:18 |
mcdonc_ | shouldnt your buildout not pull in plone then? | 20:18 |
MrTopf | the only question I have to solve is how to do authorization as they have that great concept of capabilities for auth | 20:19 |
MrTopf | well, I have a special buildout which installs Plone and those libs | 20:19 |
*** jhauser has quit IRC | 20:19 | |
mcdonc_ | oic... so what are folks complaining about? is there a separate build that just pulls in the lib? | 20:19 |
MrTopf | which is basically a plone buildout which installs the libs as externals | 20:19 |
MrTopf | well, the lib only buildout already did not work for some | 20:20 |
mcdonc_ | because it depends on zca stuff? | 20:20 |
MrTopf | and on setuptools which does not work with subversion 1.5 | 20:20 |
MrTopf | and in one case it used the zope.interface egg in site packages instead of installing a more recent one | 20:20 |
MrTopf | the setuptools was of course some unforseen incident which is only temporary until a new release is out | 20:21 |
MrTopf | but it all added to it | 20:21 |
mcdonc_ | yup | 20:21 |
MrTopf | and of course ZCA is magic to people on the first glance | 20:21 |
* mcdonc_ reads the architecture page | 20:21 | |
MrTopf | and I kept explaining it for days | 20:21 |
MrTopf | even wrote a tutorial | 20:22 |
MrTopf | or 2 | 20:22 |
MrTopf | and it was hard to see the benefits.. and of course one could also quickly implement something like this oneself... | 20:22 |
mcdonc_ | could you get away with only using zope.interface in the lib? | 20:23 |
mcdonc_ | just mark up classes with interfaces? | 20:23 |
*** jodok has joined #zope3-dev | 20:23 | |
mcdonc_ | (instead of trying to wire them up using the CA) | 20:23 |
CSWookie | Yay for ZCA | 20:23 |
MrTopf | mcdonc_: well, then the complaint was: Why use interface if there is exactly 1 interface for 1 implementation | 20:24 |
mcdonc_ | folks could either use the CA to wire them together in a separate package or choose not to... it would be documentation essentially | 20:24 |
MrTopf | but I also use adapters already and utilities | 20:24 |
MrTopf | because they make factoring out functional components easier instead of having one big class | 20:24 |
MrTopf | yes, I think that's seen now | 20:25 |
MrTopf | we also reconfirmed the use of ZCA on friday | 20:25 |
mcdonc_ | well it's probably not a library then.. it's more of an application at that point. | 20:25 |
MrTopf | the only thing now is that now some people come out of their holes who need it to run under Python 2.3 | 20:25 |
mcdonc_ | i suspect they'll have to lose | 20:25 |
MrTopf | well, there is some wiring inside the library. | 20:26 |
MrTopf | well, these are people from Linden Lab and Linden Lab uses 2.3 all over for stability reasons | 20:26 |
MrTopf | but I am not sure if LL wouldn't be better of with an internal project anyway ;-) | 20:26 |
mcdonc_ | maybe you can write it in such a way that the wiring is not required in the lib | 20:26 |
mcdonc_ | and wire it up in a separate package | 20:26 |
mcdonc_ | "let libraries be libraries" | 20:27 |
MrTopf | well, one example of where I wire is: We have an AgentDomain class which has a login() method. And you can call various functions on the agent domain (the class represents the end point). These are implemented as adapters for that agentdomain | 20:27 |
MrTopf | of course one can move the adapter registration out of the lib | 20:27 |
mcdonc_ | right | 20:28 |
MrTopf | but what does that bring? Doesn't it make sense to specify on which interface this component works? | 20:28 |
MrTopf | you can also see this as documentation | 20:28 |
MrTopf | maybe you can prevent using ISomeInterface(context) calls | 20:29 |
*** jodok has quit IRC | 20:29 | |
MrTopf | because you can also do it the hardway by using it as a normal wrapper | 20:29 |
MrTopf | SomeInterfaceImplementation(instance) | 20:29 |
mcdonc_ | there is a bit of a trick to this too | 20:29 |
mcdonc_ | if you can manage to pass in an interface to the agentdomain constructor, you can call it a "callback" | 20:29 |
MrTopf | in fact only the high level api module now uses the ISomethign(context) | 20:29 |
mcdonc_ | and folks can either use an interface or a regular python function to give them back something | 20:30 |
MrTopf | well, they can do this right now, too | 20:30 |
MrTopf | I would see it like this: There is a default wiring, if you don't want to use it, then don't use it | 20:31 |
MrTopf | either by not using the adapter calls or by overriding it via ZCA | 20:31 |
MrTopf | the latter seems to me more flexible though | 20:31 |
MrTopf | I guess an index of your own also means that one can ship PyOpenSSL in compiled form for windows | 20:33 |
mcdonc_ | likely, as long as its eggified | 20:34 |
MrTopf | as long as somebody gets it compiled ;-) | 20:34 |
MrTopf | I tried it last week | 20:34 |
MrTopf | <-- windows noob | 20:34 |
MrTopf | or one can tell people to use an installer and modify those packages which need it to not include it in their reqs | 20:35 |
MrTopf | which of course wouldn't be the ideal way | 20:35 |
mcdonc_ | i just checked out the source | 20:37 |
mcdonc_ | so what i'd suggest to get people off your back would be to parameterize the __init__ of e.g. AgentDomain | 20:37 |
mcdonc_ | and have it accept a callback, where the callback defaults to ISerializer | 20:38 |
mcdonc_ | and get rid of the REST utility | 20:38 |
mcdonc_ | and just make it a module-level function | 20:38 |
mcdonc_ | (i know you didnt ask for this, sorry to be presumptuous ;-) ) | 20:39 |
MrTopf | heh, I appreciate it nevertheless :) | 20:39 |
MrTopf | but when I make it the default then still zope.interface would be needed and thus a dependency | 20:39 |
MrTopf | I think the problems people have right now is more about all things coming together | 20:40 |
mcdonc_ | sure... but i suspect you're still going to run into the WTF factor with interfaces | 20:40 |
MrTopf | buildout problems, ZCA being magic, not seeing the benefits of it etc. | 20:40 |
MrTopf | I actually think it also settles now | 20:40 |
MrTopf | two people seem to know now what the benefits are | 20:40 |
mcdonc_ | ah ok | 20:40 |
MrTopf | the only thing might be the Python 2.3 thing | 20:41 |
mcdonc_ | that's probably irresolveable if you want to maintain sanity | 20:41 |
MrTopf | In the end it should actually be quite easy to help implementing as it mainly comes down to implementing new capabilities which basically each is one adapter and one can write recipes for how to implement these | 20:42 |
MrTopf | well, if it comes down to 2.3 I guess I am out then | 20:42 |
CSWookie | There's a dude from LL that occasionally asks Z3 related questions. I tried to explain it to him once, but I don't know how good a job I did. | 20:42 |
MrTopf | well, neither know I what sort of job I did ;-) | 20:43 |
CSWookie | questions in #python. | 20:43 |
MrTopf | apparently not that good as I kept explaining it ;-) | 20:43 |
MrTopf | but I might talk to somebody who know hopefully understood it and ask him how this tutorial can be enhanced | 20:43 |
MrTopf | CSWookie: you know his name? | 20:43 |
MrTopf | or nick | 20:43 |
CSWookie | I don't recall. I'm wanting to say Siokuden, or something like that. | 20:44 |
mcdonc_ | MrTopf: maybe you could just use a dictionary instead of an adapter lookup for capabilities and serializers/deserializers | 20:44 |
CSWookie | It was an odd name, and I've slept since then. | 20:44 |
MrTopf | Hm, no idea then | 20:44 |
MrTopf | Locklainn? | 20:44 |
MrTopf | he at least now seems to know about the benefits :) | 20:45 |
CSWookie | No, I'd probably have rememebred that. | 20:45 |
CSWookie | The name struck me as... Orientalish. | 20:45 |
MrTopf | mcdonc_: sure. I will fallback to such a solution when ZCA is not to be choosen | 20:45 |
MrTopf | Saijanai? | 20:45 |
*** afd_ has quit IRC | 20:45 | |
CSWookie | That sounds much more promising. | 20:45 |
MrTopf | I guess it was him then :) He's not working for LL though but is part of the Architecture Working Group as well | 20:46 |
MrTopf | (which was funded by LL) | 20:46 |
MrTopf | founded | 20:46 |
MrTopf | not funded :) | 20:46 |
*** andres_f has quit IRC | 20:46 | |
MrTopf | mcdonc_: my main argument here is that somebody already implemented a registry so why not use it | 20:47 |
MrTopf | next thing would be maybe events which I would also see as being useful in that library | 20:47 |
CSWookie | I probably misunderstood him then. He said he was working on specs for some Second Life thing. | 20:47 |
MrTopf | yes, we are working on the Open Grid Protocol | 20:47 |
mcdonc_ | MrTopf: well, i suspect the response will be "why not a dictionary", which is a reasonable question for simple adapter lookups | 20:47 |
MrTopf | it's a joint effort between Linden Lab and everybody who wants to contribure | 20:47 |
MrTopf | contribute | 20:47 |
MrTopf | mcdonc_: as said, we confirmed ZCA now so I will stick to that now :) | 20:48 |
mcdonc_ | yup | 20:48 |
MrTopf | if for some reason we again question this decision we can do it like that. My main point is that we don't end up with Zope2ish class structures if possible | 20:48 |
MrTopf | and don't stick with 2.3 ;-) | 20:49 |
mcdonc_ | setuptools entry points are also good registries | 20:49 |
MrTopf | I don't even get 2.3 compiled without problems on my mac | 20:49 |
MrTopf | oh, that's magic, too ;-) | 20:49 |
MrTopf | I would then stay with dicts | 20:49 |
mcdonc_ | yup | 20:50 |
*** andres has joined #zope3-dev | 20:50 | |
MrTopf | for now I wonder why my views are not registered ;-) | 20:50 |
mcdonc_ | the main use case for adapters is the same as it would be for "multimethods"... but if there is exactly one named imlplementation of an adapter and you dont do a dispatch on the caller type, adapters are not as useful. | 20:50 |
mcdonc_ | because then it really is just a dictionary | 20:51 |
MrTopf | but if you start without them you might end up faster with big classes. | 20:51 |
MrTopf | I sorta like the way of thinking they imply | 20:51 |
MrTopf | and going from doctests => interface => implementation also makes sense to me | 20:51 |
MrTopf | and yes, you can do all of that without ZCA | 20:52 |
MrTopf | you just need some coding guidelines | 20:52 |
mcdonc_ | in bfg we use the hell out of the CA internally but there's no assumption that folks will use it to make apps, except to associate views with models... which feels about right. | 20:54 |
MrTopf | well, in pyogp I could imagine people registering the own event handlers for their app | 20:55 |
MrTopf | as in the end it will be mainly an event loop | 20:55 |
mcdonc_ | yup.. although they might choose to use their own event system... the zope.event system is 4 lines long. | 20:55 |
mcdonc_ | and biting off the CA to use it is a lot. | 20:56 |
CSWookie | mcdonc_: I'm amused by the name bfg, by the way. Why did you select it? | 20:56 |
MrTopf | but isn't it based on the ZCA and 4 lines long because of that? | 20:56 |
MrTopf | ok, you can of course again do a dictionary or list | 20:56 |
mcdonc_ | CSWookie: i wanted to use "ZF1" (from Fifth Element) but the 1 in the name would have been too confusing... so bfg it was ;-) | 20:57 |
MrTopf | but in the end you can do this all the time.. so why doesn't Zope3 use more dict and lists? ;-) | 20:57 |
MrTopf | but actually in the end you will have something similar like ZCA, just based on dicts and lists, so I still wonder, why not use ZCA in the first place | 20:58 |
MrTopf | it's implemented, it's documented, it gives you an interface some people might be familiar with | 20:58 |
CSWookie | Because 'Zope' is a big scary word? | 20:58 |
MrTopf | I also see the danger though in overusing components because then it quickly becomes complicated to understand the structure | 20:59 |
mcdonc_ | MrTopf: i think its mostly a matter of "pay for what you eat"... an app is a reasonable place to rely on the CA. A library might not be, because in order to use the library, you need to "pay" for "eating" the CA. | 20:59 |
mcdonc_ | and if the problem space can reasonably be solved with simpler stuff, it's not a horrible argument against it. | 21:00 |
MrTopf | maybe I should then propose to get rid of ZCA after I was voting for it all the time :) | 21:00 |
mcdonc_ | well, probably not.. but you might consider getting rid of it in the *base* library.. and have an extension "app" that wires it up with the CA. | 21:01 |
MrTopf | but I still don't see the difference. you have to pay for understanding how the lib is wired anyway (or how you can wire it) | 21:01 |
mcdonc_ | well, maybe it's a matter that the library shouldnt need any wiring and the wiring happens above | 21:01 |
MrTopf | well, the adapter example comes up again.. then it needs to be in the docs on which classes/interfaces you can use that adapter | 21:02 |
*** jodok has joined #zope3-dev | 21:02 | |
mcdonc_ | you can poke in interfaces from the outside too onto a class | 21:02 |
mcdonc_ | just for example, if the base lib just implemented classes that were useful for an arbitrary python app | 21:03 |
mcdonc_ | you'd move the stuff that relied on adapter lookups to a higher level | 21:04 |
MrTopf | well, I still like the idea of interfaces as documentation though | 21:04 |
mcdonc_ | sure | 21:04 |
mcdonc_ | i think it's just a matter of factoring "for the masses" | 21:04 |
mcdonc_ | no oss developer wants to learn anything new | 21:05 |
mcdonc_ | especially if they cant reuse the knowledge in their day job | 21:05 |
* MrTopf uses ZCA all the time after having it learned for Zope/Plone ;-) | 21:06 | |
MrTopf | or buildout | 21:06 |
mcdonc_ | sure... but there are tons of TG developers who use PEAK Rules to get multimethods, and they'd want to use that. | 21:06 |
mcdonc_ | and you'd be like "WTF is this?" ;-) | 21:06 |
MrTopf | well, I have no problem with learning something new :) | 21:07 |
MrTopf | so what is it? :) | 21:07 |
MrTopf | well, I will see how things go now in this project | 21:08 |
mcdonc_ | http://peak.telecommunity.com/DevCenter/RulesReadme | 21:08 |
MrTopf | the important part, as said, to me is that it's coded in a sane style | 21:08 |
MrTopf | and maybe ideas from how you would do it with ZCA are used if not ZCA itself | 21:09 |
mcdonc_ | i'm just a busybody, don't listen to me ;-) | 21:09 |
MrTopf | from the outside I would even say that you don't need to know about ZCA necessarily | 21:09 |
MrTopf | now though my views in my plone site are not found ;-) | 21:09 |
MrTopf | and I suspect my configure.zcml not even read as I just wrote nonsense inside it, restarted and nothing complained.. | 21:10 |
mcdonc_ | oh its one of those products thats not a product eh | 21:10 |
mcdonc_ | <five:package or something | 21:11 |
*** jhauser has joined #zope3-dev | 21:11 | |
MrTopf | well, it does not need to be a product I think | 21:11 |
MrTopf | it just has some views, no content types | 21:11 |
MrTopf | but it maybe helps to put it into the zcml-slugs part | 21:11 |
mcdonc_ | yup | 21:11 |
mcdonc_ | it wont be read automagically unless it's included in there | 21:12 |
MrTopf | yeah, I actually knew this ;-) | 21:12 |
mcdonc_ | or you turn it into a zope2 product and use the five:package thing | 21:12 |
MrTopf | ok, now my nonsense fails | 21:12 |
mcdonc_ | woo hoo for failing nonsense! | 21:12 |
mcdonc_ | nice tests btw | 21:13 |
*** vipod has joined #zope3-dev | 21:14 | |
MrTopf | you probably mean the message parser stuff | 21:14 |
mcdonc_ | indeed | 21:15 |
MrTopf | these are done by a Linden Lab guy who takes this serious :) | 21:15 |
MrTopf | I just wrote some lousy doctests ;-) | 21:15 |
MrTopf | I was busy fixing buildout failures | 21:16 |
mcdonc_ | the doctests look pretty good too | 21:16 |
MrTopf | thanks, but there need to be more tests actually | 21:17 |
mcdonc_ | except the caps.txt imports "Capability" but doesn't actually use it | 21:17 |
MrTopf | right, it maybe should | 21:17 |
MrTopf | SeedCapability is a special case of a Capability though and most of the stuff should be tested by using that but nevertheless.. | 21:18 |
MrTopf | oh, and SC returns Capabilities, so in fact it is tested to some extent as I then call them | 21:18 |
mcdonc_ | so the AgentDomain is the "jumping off point"? its what listens? | 21:18 |
MrTopf | look at api.py | 21:19 |
MrTopf | it starts with a credential object which then gets passed to the agend domain login method | 21:19 |
MrTopf | and this is the starting point then | 21:19 |
MrTopf | it returns the seed capability if login was ok | 21:19 |
mcdonc_ | ic | 21:19 |
MrTopf | (internally) | 21:20 |
MrTopf | the login method itself returns an agent object which holds a reference to the agent domain and thus the seed cap | 21:20 |
*** regebro has quit IRC | 21:20 | |
MrTopf | and all the capabilities are then called on the agent domain | 21:20 |
MrTopf | or later on a region when the agent chooses to rez on some piece of virtual land (=region) | 21:21 |
MrTopf | then the event loop comes into play | 21:21 |
MrTopf | and something called reverse http | 21:21 |
MrTopf | here is some writeup about capabilities btw: http://mrtopf.de/blog/secondlife/slga-capabilities-explained-technical/ | 21:21 |
MrTopf | they are used instead of header based auth | 21:21 |
* mcdonc_ reads | 21:23 | |
MrTopf | I am not really a fan of them though.. but it's what LL uses internally so right now there probably is no way around | 21:24 |
mcdonc_ | is the basic idea that you only need to send your username and password once? | 21:26 |
mcdonc_ | to get the seed capability? | 21:26 |
CSWookie | Huh... Since the cap url is sent via http, wouldn't be possible to get it via snooping? | 21:26 |
* CSWookie is feeling a little dumb to be asking that question, since it must have been thought about... | 21:27 | |
MrTopf | should be https | 21:27 |
MrTopf | mcdonc_: yes | 21:27 |
CSWookie | OH, your examples say http. | 21:27 |
MrTopf | well, then I suck ;-) | 21:27 |
MrTopf | thanks for spotting this :) | 21:27 |
*** sunew has joined #zope3-dev | 21:28 | |
CSWookie | NP. | 21:28 |
* MrTopf changed something | 21:29 | |
MrTopf | I should check what Linden Lab actually returns | 21:29 |
mcdonc_ | these folks have no business telling you the CA is complex ;-) | 21:29 |
MrTopf | mcdonc_: heh :) | 21:29 |
MrTopf | well, caps in itself are also easy once you understood them | 21:29 |
MrTopf | and that took me a while | 21:30 |
MrTopf | until I understood that the caps server in fact is mostly a proxy | 21:30 |
MrTopf | but maybe a SPOF | 21:30 |
MrTopf | and the seed capability also shouldn't go down | 21:30 |
MrTopf | and it needs to know about all the URLs and permissions itself | 21:30 |
MrTopf | why usually in web frameworks you attach that information to the function | 21:31 |
mcdonc_ | that last bit is what i tried to go for in repoze.decsec | 21:31 |
MrTopf | and this actually also is my challenge of using it with plone because I have to switch of all security of my views in order for the caps server to access them | 21:31 |
mcdonc_ | attaching authorization info to URLs | 21:31 |
MrTopf | like caps? where you get a different token for every function you want to use? | 21:32 |
MrTopf | or move it from cookie to URL basically? | 21:32 |
MrTopf | the other problem is that you always have an extra roundtrip for retrieving the token | 21:32 |
MrTopf | you might be able to reuse it and you can collect many of them at once though | 21:33 |
MrTopf | but some might expire | 21:33 |
mcdonc_ | no... it's more like zope whereby you create a graph of security declarations, and compare the security declaration you find (by virtue of matching the URL against the graph of declarations) against the authenticated user | 21:33 |
MrTopf | so in this case you have 2 roundtrips then, one with an error, then getting a new one and then finally calling the function | 21:33 |
MrTopf | ic | 21:34 |
mcdonc_ | like http basic auth | 21:34 |
mcdonc_ | (wrt to the roundtrip) | 21:34 |
MrTopf | yes, but that stays then | 21:34 |
MrTopf | and you can access all sorts of paths then | 21:34 |
MrTopf | with caps you have to ask for every resource you want to access | 21:35 |
mcdonc_ | i kinda wonder why a session id wouldnt have been good enough | 21:35 |
mcdonc_ | i guess it can be snooped | 21:36 |
mcdonc_ | duh | 21:36 |
*** vimes656 has quit IRC | 21:36 | |
MrTopf | your seed cap could be snooped as well | 21:38 |
MrTopf | or your pw in the first place | 21:38 |
MrTopf | the main reason I think is that here all the components don't have to worry about authorization | 21:39 |
MrTopf | they get some URL to some resource and answer | 21:39 |
MrTopf | and you can only call it form the outside when you first asked for a public URL with some uuid | 21:40 |
MrTopf | and some central authority (the seed cap) has your session and knows that you are user x and your inventory is stored at http://privatemachine/inventory/users/x/ | 21:40 |
MrTopf | and creates a mapping from this to some public URL which it can give out | 21:40 |
MrTopf | and privatemachine does not need to know anything else about you and your permissions | 21:41 |
MrTopf | but this setup directly needs some sort of firewall or at least multiple servers (where one runs on 127.0.0.1 in order to be private) | 21:41 |
mcdonc_ | where is "privatemachine"? "behind" the capability server? | 21:42 |
mcdonc_ | and the capability server is essentially the firewall? | 21:43 |
MrTopf | it's behind the firewall (privatemachine) | 21:44 |
MrTopf | and the caps server is a proxy inside the firewall | 21:44 |
MrTopf | proxy with a mapping | 21:44 |
MrTopf | the private site send it messages like grantCap(privateurl, timeout, oneshot=False) | 21:45 |
MrTopf | and it creates a new UUID and constructs a public URL with it and stores the mapping publicurl,privateurl inside some database and returns the public url | 21:45 |
MrTopf | and on the public interface it listens for things like /cap/<uuid> and proxies it to privateurl | 21:45 |
MrTopf | right now my public url in Plone is actually the same as private url | 21:46 |
MrTopf | I might bake in some auth into the url to add some security to it | 21:46 |
MrTopf | like back then with that old session id stuff inside the URL | 21:47 |
mcdonc_ | your plone app is what kind of server wrt to your diagram at http://mrtopf.de/blog/secondlife/slga-capabilities-explained-technical/? It has the same duty as the "Assets" server or "IM" server? | 21:49 |
MrTopf | It's the Agent Host | 21:49 |
mcdonc_ | aw hell ;-) | 21:49 |
MrTopf | and it might implement IM, inventory etc. | 21:49 |
MrTopf | well, maybe I do not all of this with Plone ;-) | 21:49 |
MrTopf | this really is just some experiment to get the interface of pyogp.lib.agentdomain right | 21:50 |
MrTopf | and right now we only have login and placing the avatar on a region anyway | 21:50 |
MrTopf | which involves 3 caps I think | 21:50 |
* mcdonc_ checks it otu | 21:52 | |
MrTopf | right now there shouldn't be too much working | 21:53 |
MrTopf | and you'd need some account in Second Life of course. One that also is already on the beta grid | 21:53 |
MrTopf | but somebody might set this up maybe :) | 21:54 |
mcdonc_ | i dont see any plone imports anywhere | 21:56 |
MrTopf | what did you check out? | 21:57 |
MrTopf | I am not sure that my stuff is already checked in | 21:57 |
mcdonc_ | pyogp.lib.agentdomain | 21:58 |
mcdonc_ | (and base) | 21:58 |
MrTopf | no, they are supposed to have no imports from Plone | 21:59 |
MrTopf | let me check | 21:59 |
MrTopf | ok, I did not yet check it in ;-) | 21:59 |
MrTopf | as there is not much yet to check in | 21:59 |
MrTopf | I hope to have some progress today (then again it's getting kinda late here) | 21:59 |
mcdonc_ | ok well i'll stop bugging you, sorry... its just sort of interesting ;-) | 21:59 |
MrTopf | I will tell you when there is something to see :) | 22:00 |
MrTopf | hopefully with some instructions on how to setup your own test sandbox with your own region | 22:00 |
MrTopf | in this case no LL server would be required | 22:00 |
MrTopf | some IBM guy is working on a patch for OpenSim to support this protocol | 22:00 |
MrTopf | here are my slides from EuroPython btw: http://www.slideshare.net/mrtopf/europython-2008-tear-down-the-walls-of-virtual-worlds | 22:01 |
mcdonc_ | if you check in your stuff i will try to turn it into a bfg app just for fun | 22:01 |
MrTopf | cool | 22:01 |
mcdonc_ | wow. that's one nice looking presentation. | 22:04 |
MrTopf | thanks :) | 22:04 |
MrTopf | not sure it makes sense without the blabla around it though | 22:04 |
mcdonc_ | it doesnt matter, it's pretty ;-) | 22:05 |
*** timte_ has quit IRC | 22:06 | |
MrTopf | :-) | 22:06 |
MrTopf | so now I need to find out how to check the password manually | 22:06 |
mcdonc_ | the deserialze gets you the payload with the login and password in it? | 22:08 |
MrTopf | yes, deserialization of the credential | 22:08 |
MrTopf | it comes all in form of LLSD, some XML dialect | 22:08 |
mcdonc_ | and now you need to check it against the login server? | 22:09 |
MrTopf | yes, I just found AuthEncoding.pw_encrypt() | 22:09 |
MrTopf | now I only need to know where PAS stores the pw | 22:09 |
MrTopf | PAS is also a mistery to me, btw ;-) | 22:09 |
MrTopf | is there some good docs on it somewhere? | 22:09 |
mcdonc_ | no. | 22:10 |
*** andres_f has joined #zope3-dev | 22:10 | |
* mcdonc_ looks at the PAS source | 22:10 | |
MrTopf | great ;-) | 22:10 |
MrTopf | well, that's what I do right now | 22:10 |
MrTopf | I guess the proper way would be to ask some auth plugin | 22:11 |
MrTopf | the problem is though that SL users come as firstname lastname | 22:11 |
MrTopf | so I first check memberdata now to find a user that fits it | 22:11 |
mcdonc_ | you probably dont want to mix up memberdata and auth data (because although they are related, they should be only loosely) | 22:12 |
mcdonc_ | i think the pas way would be to write an IExtraction plugin | 22:12 |
MrTopf | maybe I should use bfg... | 22:12 |
MrTopf | well, for now I mix them up, it's all a proof of concept right now | 22:13 |
mcdonc_ | well, you could just ditch pas | 22:13 |
mcdonc_ | and do all the work brutally in the views | 22:13 |
mcdonc_ | against some dictionary | 22:13 |
mcdonc_ | "pay for what you eat" ;-) | 22:13 |
MrTopf | well, I maybe simply implement some AT object which stores username and some password | 22:14 |
mcdonc_ | sure | 22:14 |
MrTopf | I need to ditch security on the views anyway if I want to go with a real caps server | 22:14 |
mcdonc_ | it probably doesnt make too much sense to associate the user with a zope user if they're never actually going to use the zopey bits | 22:15 |
MrTopf | well, I was planning to put the auth cookie into the URL | 22:16 |
MrTopf | and let PAS check this | 22:16 |
mcdonc_ | i suppose you could log in via a method that just brutalizes the body and redirects | 22:16 |
mcdonc_ | (setting the cookie) | 22:16 |
mcdonc_ | you wouldnt actually need to check authentication creds at that point | 22:17 |
mcdonc_ | just set the cookie and redirect | 22:17 |
mcdonc_ | then let pas do its job thereafter | 22:17 |
mcdonc_ | plone overrides the cookie auth in "base" pas | 22:18 |
mcdonc_ | there's some function in that shitpile to set the cookie | 22:18 |
MrTopf | but then my client lib would also need to follow that redirect and support cookies | 22:20 |
MrTopf | well, for now I simply won't check the pw :) | 22:20 |
MrTopf | I mean everything else is not protected anyway | 22:20 |
MrTopf | I guess there might be some need for an CMS out there which it's easy to develop for | 22:22 |
mcdonc_ | heh | 22:22 |
mcdonc_ | you could do this: | 22:23 |
mcdonc_ | site.acl_users.cookie_auth.updateCredentials(request, response, login, password) | 22:23 |
mcdonc_ | its cheating but itd work | 22:23 |
*** andres has quit IRC | 22:23 | |
MrTopf | ic | 22:23 |
MrTopf | what this return something meaningful or just set a cookie? | 22:24 |
mcdonc_ | it just sets the cookie | 22:24 |
MrTopf | so I could check the cookie in the response to see whether it worked or not? | 22:24 |
MrTopf | Hm does not look like it | 22:25 |
MrTopf | looks like it sets the cookie for whatever you provide | 22:25 |
mcdonc_ | yes | 22:25 |
mcdonc_ | it does no checking | 22:25 |
MrTopf | well, I acually just need the checking | 22:26 |
MrTopf | but anyway, I will go without check for now | 22:26 |
MrTopf | I want to get to the core of my problem now :) | 22:26 |
MrTopf | I probably would be finished with Django by now | 22:26 |
mcdonc_ | to check the credentials you can use acl_users.zodb_users.authenticateCredentials, mydict) | 22:26 |
MrTopf | next step would be to have some nice starting point for those views and I was thinking about some traversal adapter | 22:27 |
mcdonc_ | where mydict is {'login':'foo', 'password':'bar'} | 22:27 |
MrTopf | but these also seem never to do what I expect from them | 22:27 |
MrTopf | ah, thanks | 22:27 |
MrTopf | I will write this down for now and put in later | 22:27 |
mcdonc_ | it will return None if it can't authenticate i think | 22:27 |
MrTopf | I will find it out | 22:28 |
mcdonc_ | oops that should be acl_users.zodb_users.authenticateCredentials(mydict) | 22:28 |
MrTopf | :-) | 22:29 |
mcdonc_ | you you need to ditch plone for this i think | 22:29 |
mcdonc_ | anything would be better... | 22:29 |
MrTopf | but Plone has more PR value ;-) | 22:30 |
mcdonc_ | only because we keep propping it up ;-) | 22:31 |
MrTopf | but in the long run Plone maybe needs to change somehow anyway.. just looking at all the things involved in users and userdata... | 22:31 |
MrTopf | membership tool, memberdata tool, various plugins in PAS | 22:31 |
elro | +100 | 22:31 |
MrTopf | well, so far I have no alternative when it comes to CMS | 22:31 |
MrTopf | Drupal maybe :) | 22:32 |
mcdonc_ | for this, maybe a cms isnt what you need | 22:32 |
MrTopf | well, I keep going for this evening now | 22:32 |
MrTopf | plone.reload also seems not to be active... | 22:33 |
mcdonc_ | can you point me at the code that deserializes the body with the login and password in it? | 22:34 |
MrTopf | so next try would be with Django | 22:34 |
MrTopf | let me try to understand my code ;-) | 22:34 |
mcdonc_ | i know the feeling | 22:35 |
*** jpcw2002 has joined #zope3-dev | 22:36 | |
MrTopf | I guess I deleted it by accident by some refactoring.. | 22:36 |
MrTopf | or maybe I also never checked this in ;-) | 22:36 |
MrTopf | but the basic function to deserialize something is in the indra.llsd package | 22:36 |
MrTopf | you can easy_install it | 22:36 |
mcdonc_ | ok | 22:37 |
MrTopf | and then you have parse(xml) | 22:37 |
MrTopf | and format_xml(dict) | 22:37 |
MrTopf | see http://svn.secondlife.com/svn/linden/projects/2008/pyogp/pyogp.lib.base/trunk/pyogp/lib/base/caps.py | 22:37 |
MrTopf | for some examples | 22:37 |
MrTopf | I will quickly add it to the lib now | 22:38 |
*** jodok has quit IRC | 22:40 | |
mcdonc_ | what are you expecting for an unauthorized response? a 401? | 22:41 |
mcdonc_ | (in the client lib) | 22:41 |
MrTopf | 403 Forbidden | 22:43 |
MrTopf | btw, we have meetings on mon/wed/fri about pyogp if you want to join :) | 22:44 |
*** jodok has joined #zope3-dev | 22:45 | |
*** philiKON has joined #zope3-dev | 22:46 | |
MrTopf | Mr philiKON1 | 22:46 |
MrTopf | ! | 22:46 |
philiKON | hey | 22:47 |
MrTopf | how's life? :) | 22:48 |
philiKON | good good | 22:48 |
*** quodt has joined #zope3-dev | 22:51 | |
MrTopf | mcdonc_: the deserializer needs to be rewritten anyway because the payload I get does not say anything about what sort of credential it is. it might not be plaintest but might be md5 instead | 22:51 |
MrTopf | actually that's in the spec defined but it's not yet implemented like this | 22:51 |
mcdonc_ | ic | 22:52 |
MrTopf | so I don't know which class to instantiate | 22:53 |
MrTopf | I assume for now plain password | 22:53 |
MrTopf | mcdonc_: http://svn.secondlife.com/svn/linden/projects/2008/pyogp/pyogp.lib.base/trunk/pyogp/lib/base/credentials.py | 22:55 |
MrTopf | and here is the test for it: http://svn.secondlife.com/svn/linden/projects/2008/pyogp/pyogp.lib.base/trunk/pyogp/lib/base/tests/login.txt | 22:55 |
MrTopf | (at the bottom) | 22:55 |
MrTopf | and there is also #pyogp btw ;-) | 22:56 |
*** jodok_ has joined #zope3-dev | 22:56 | |
*** jodok has quit IRC | 22:56 | |
mcdonc_ | its a bit of a bug that there isnt a indra.llsd.parse_file that doesnt assume you want to read the entire string into memory | 22:58 |
mcdonc_ | but i guess you can check if the content-length is sane | 22:59 |
MrTopf | well, the indra.llsd package is also just insofar open source as that you can get the source | 22:59 |
MrTopf | I don't know what the process there is if you want to change something | 22:59 |
MrTopf | I just eggified it on my own now | 22:59 |
MrTopf | it's also some wild collection of things anyway | 22:59 |
MrTopf | the whole indra thing | 22:59 |
MrTopf | right now the messages are small though. we will see how big they are when we start working on inventory | 23:00 |
MrTopf | textures come to mind | 23:00 |
mcdonc_ | this is why people use headers to transfer authentication information, because when you need to read the body to get it, all sorts of weirdnesses happen | 23:01 |
MrTopf | but that library is in use at LL so I guess it somehow works | 23:01 |
MrTopf | well, with caps you only need the URL | 23:02 |
*** jodok has joined #zope3-dev | 23:02 | |
*** jodok_ has quit IRC | 23:03 | |
*** Jell-O-Fishi has joined #zope3-dev | 23:04 | |
mcdonc_ | MrTopf: is there a special user-agent for the client? | 23:14 |
MrTopf | what do you mean? | 23:15 |
MrTopf | you mean as header? | 23:15 |
mcdonc_ | yes | 23:15 |
mcdonc_ | to disambiguate it from a "normal" browser request | 23:15 |
mcdonc_ | or any way to do that really | 23:15 |
MrTopf | no, not at this point | 23:16 |
MrTopf | the assumption is I guess that those servers will be just for the OGP client and not normal web browsers | 23:17 |
MrTopf | there are probably too many assumption in the whole thing which come from LL's way of working | 23:17 |
MrTopf | but one might bring this up at the next meeting | 23:17 |
MrTopf | Hm, can't I adapt a acquisition wrapper object? | 23:18 |
MrTopf | I return some fresh agent object with return agent.__of__(self.context) and then the next method tries to adapt it to IAgent a la IAgent(agent) | 23:19 |
MrTopf | which fails | 23:19 |
mcdonc_ | i'm pretty sure you can | 23:19 |
mcdonc_ | hmmm. | 23:19 |
mcdonc_ | dont do that? ;-) | 23:19 |
*** jodok has quit IRC | 23:20 | |
MrTopf | well, I somehow need to construct the URL in that adapter | 23:20 |
mcdonc_ | make it a multiadapter and have it accept the request too? | 23:20 |
MrTopf | Hm, the function adapting it is not in Plone but in the library | 23:21 |
mcdonc_ | although maybe that doesnt solve it | 23:21 |
MrTopf | so it does not know about the request | 23:21 |
MrTopf | and shouldn't | 23:21 |
mcdonc_ | right | 23:21 |
*** jodok has joined #zope3-dev | 23:21 | |
MrTopf | the idea is that the login method can return any object (like a normal user object) but also needs to provide an adapter to implement IAgent | 23:21 |
MrTopf | which has a property called "seedcap" which should be the URL to the seed capability | 23:21 |
MrTopf | but isn't every normal Zope object also wrapped anyway? | 23:22 |
MrTopf | TypeError: ('Could not adapt', <ImplicitAcquirerWrapper object at 0x669be70>, <InterfaceClass pyogp.lib.agentdomain.interfaces.IAgent>) | 23:22 |
mcdonc_ | anything obtained via traversal is anyway | 23:22 |
MrTopf | in this case it's more a virtual object | 23:23 |
MrTopf | I create it on the fly when the client asks for a user | 23:23 |
MrTopf | and is derived from SimpleItem | 23:23 |
mcdonc_ | that should work fine | 23:23 |
MrTopf | ah, I am doing something wrong :) | 23:24 |
MrTopf | ok, nvm :) | 23:24 |
mcdonc_ | what should be in the cookie? the firstname, lastname, and password? or just a login and a password where the login is derived from the first name and the lastname? | 23:30 |
MrTopf | you mean credential | 23:30 |
MrTopf | ? | 23:30 |
*** sunew has quit IRC | 23:30 | |
mcdonc_ | yeah | 23:30 |
mcdonc_ | i mean, i'm writing something that parses the body xml and sets a cookie | 23:31 |
MrTopf | well, in the Open Grid Protocol there actually are no cookies used | 23:31 |
MrTopf | or maybe I misunderstand what you are doing :) | 23:32 |
mcdonc_ | i think i do too ;-) | 23:32 |
mcdonc_ | you were originally trying to set a cookie at some point | 23:32 |
MrTopf | and I wonder: don't I instaniate a SimpleItem with an id? | 23:32 |
MrTopf | well, not really, I was thinking about how to check the password | 23:32 |
mcdonc_ | you'll have to look at OFS.SimpleItem | 23:32 |
MrTopf | there is no __init__() and I wonder which superclass implements it ;-) | 23:32 |
mcdonc_ | who fucking knows ;-) | 23:33 |
MrTopf | but the tests do instantiate it like this | 23:33 |
MrTopf | ok, pdb time.. | 23:33 |
mcdonc_ | so under what circumstance is your app going to get a request with one of these llnd bodies in it | 23:33 |
mcdonc_ | every request? | 23:33 |
*** yota has quit IRC | 23:35 | |
MrTopf | I have views for login, the seed capability and the place_avatar capability | 23:35 |
MrTopf | and they all get LLSD | 23:35 |
MrTopf | and it's open right now how they know if the person is authorized | 23:35 |
mcdonc_ | ic | 23:35 |
MrTopf | so right now it will just do for everybody | 23:35 |
MrTopf | one idea was to return URLs like /<authcode>/agent/@@seedcap | 23:36 |
MrTopf | instead of using a caps server | 23:36 |
MrTopf | but I actually have a caps server running so I can also use this | 23:36 |
MrTopf | the only thing is that login needs to be public | 23:36 |
mcdonc_ | i'm in over my head i think. | 23:36 |
MrTopf | well, right now I use URLs like /agents/<username>/@@seedcap | 23:37 |
MrTopf | or probably ++agents++username/ or so | 23:37 |
MrTopf | and seedcap is the endpoint of the seed capability | 23:37 |
MrTopf | so you send it LLSD formatted lists like ['place_avatar'] | 23:38 |
mcdonc_ | chicken and egg thing going on i think. | 23:38 |
MrTopf | and it needs to return some public URL for this capability | 23:38 |
*** jodok_ has joined #zope3-dev | 23:38 | |
MrTopf | I now always return /agents/<username>/@@place_avatar | 23:38 |
MrTopf | and this is some function defined in the spec with the payload it expects | 23:39 |
MrTopf | here is the not so uptodate spec: http://wiki.secondlife.com/wiki/SLGOGP_Draft_1 | 23:39 |
mcdonc_ | given that the client stuff accesses the url "/agents/<username>/@@seedcap", you eventually want to challenge if the request does not contain information that would prove that this user is "username", right? | 23:39 |
MrTopf | yes, what's missing is some sort of authentication here | 23:40 |
MrTopf | this is what the caps server usually is good for | 23:40 |
MrTopf | you prove on login and you get some cryptic URL instead as the seed cap | 23:41 |
MrTopf | internally it might resolve to the one above | 23:41 |
mcdonc_ | but in "production" you wont need the authentication right? | 23:41 |
mcdonc_ | because you'll assume that the login server has done the job for you? | 23:41 |
MrTopf | well, if I have such a caps server in place | 23:41 |
*** dunny has joined #zope3-dev | 23:41 | |
MrTopf | only with a caps server which shields these urls because otherwise people of course could guess that URL | 23:41 |
MrTopf | the login service is public and you send some credentials to it | 23:42 |
MrTopf | then it checks it and if it's ok it will compute that seedcap URL and will then ask the capsserver to grant a cap for it | 23:42 |
mcdonc_ | i guess i'm wondering how the caps server could be optional in such a setup | 23:42 |
MrTopf | the capsserver then returns a cryptic unguessabl URL | 23:42 |
MrTopf | well, right now it can't be | 23:42 |
MrTopf | but I might return some URL like /c7dzdcscdhbsjhbdjhbds/agents/<username>/@@seedcap | 23:43 |
MrTopf | and that path element in front maybe could be eaten by PAS | 23:43 |
MrTopf | not sure if it can eat path elements | 23:43 |
MrTopf | but i could also put it behind the URL as query parameter | 23:43 |
mcdonc_ | probably not pas' job | 23:43 |
MrTopf | I could write some traverser | 23:44 |
MrTopf | and make it as obfuscated as possible ;-) | 23:44 |
*** jodok__ has joined #zope3-dev | 23:44 | |
MrTopf | or use some WSGI middleware ;-) | 23:44 |
MrTopf | but I don't care that much about this part right now before not the caps are working itself without security | 23:45 |
MrTopf | I could always put a caps server in front | 23:45 |
*** jodok__ has quit IRC | 23:45 | |
MrTopf | I even have one | 23:45 |
*** jodok has quit IRC | 23:45 | |
MrTopf | ok, now I wonder if I use SimpleItem correctly | 23:45 |
mcdonc_ | i think maybe you want /agents/<username>/seedcap/8asduasdhasdh | 23:45 |
mcdonc_ | and write "seedcap" in such a way that it has a bobo_traverse that's willing to eat the random stuff | 23:46 |
MrTopf | yep | 23:47 |
MrTopf | but not with bobo* :) | 23:47 |
*** jodok has joined #zope3-dev | 23:47 | |
MrTopf | but IPublishTraverse | 23:47 |
mcdonc_ | or before_publishing_traverse or whatever other travesty | 23:47 |
MrTopf | I wish one would have things like those urlmapper from django in Zope/PLone | 23:47 |
MrTopf | would make some stuff like this easier | 23:48 |
mcdonc_ | you can, if you use bfg | 23:48 |
MrTopf | :-) | 23:48 |
MrTopf | I should propose to the pyogp people to use bfg :) | 23:48 |
mcdonc_ | http://static.repoze.org/bfgdocs/api/urldispatch.html | 23:48 |
MrTopf | just for the fun of discussing things :) | 23:48 |
MrTopf | nice | 23:49 |
MrTopf | I will base my next CMS on bfg then | 23:49 |
mcdonc_ | or pylons | 23:49 |
MrTopf | but do you also do URL traversal? | 23:49 |
mcdonc_ | anything but plone for this | 23:49 |
mcdonc_ | yeah, graph traversal is the default | 23:49 |
MrTopf | ic, cool | 23:49 |
mcdonc_ | http://static.repoze.org/bfgdocs/tutorials/lxmlgraph/index.html | 23:50 |
mcdonc_ | a website with the "model" data implemented as an xml document | 23:51 |
MrTopf | i will have a look at this later :) | 23:51 |
MrTopf | I now solved my problem be ditching SimpleItem | 23:52 |
MrTopf | and deriving from object | 23:52 |
MrTopf | and passing the context in there | 23:52 |
mcdonc_ | sigh | 23:52 |
MrTopf | as said, just proof of concept :) | 23:53 |
MrTopf | tomorrow then the next try with grok/bfg/django/pylons/TG | 23:53 |
*** sunew has joined #zope3-dev | 23:58 | |
*** jodok_ has quit IRC | 23:59 |
Generated by irclog2html.py 2.15.1 by Marius Gedminas - find it at mg.pov.lt!