srichter | anyone still here? | 00:28 |
---|---|---|
srichter | is in REST GET & POST pretty much the same thing? | 00:28 |
gintas | srichter, what? | 00:32 |
gintas | GET is for getting state | 00:32 |
gintas | POST is for submitting data to be processed on the server | 00:33 |
gintas | I'm not sure I understood the question | 00:33 |
srichter | GET = view, POST = edit, PUT = add | 00:33 |
gintas | not necessarily | 00:34 |
gintas | PUT could be edit too | 00:34 |
gintas | GET and PUT are the inverses | 00:35 |
gintas | with PUT you 'put' data to a particular URI | 00:36 |
gintas | later if you try to 'GET' from that URI, you will receive the same data | 00:36 |
gintas | that's a simplified definition of PUT | 00:36 |
gintas | if, on the other hand, you send data and it ends up in some different URI, or it is processed by the server and converted into a different format (or a side effect takes place), that's a POST | 00:37 |
gintas | PUTs are usually idempotent (doesn't matter how many times you do it) | 00:37 |
srichter | ok | 00:37 |
gintas | oh, I think I understood why you asked this ;) if you want to make a complex query, a POST might be favourable over GET | 00:43 |
srichter | I am asking because of documentation | 00:44 |
srichter | so every object, IPerson, IGroup, etc. should really have at most one GET, POST, PUT, DELETE | 00:45 |
srichter | gintas: right? | 00:46 |
gintas | yes | 00:46 |
gintas | objects identified by URIs are 'nouns' | 00:46 |
gintas | GET, POST, PUT, DELETE are the only allowed 'verbs' | 00:46 |
srichter | ok | 00:47 |
srichter | now the tricky things will be the traversers | 00:47 |
srichter | I might not get enough info from them | 00:47 |
srichter | mmhhh | 00:47 |
gintas | it's local code, so we can devise a convention to provide the missing info if it's really neaded | 00:48 |
gintas | s/neaded/needed/ | 00:48 |
gintas | right, traversers can't tell what you can traverse into at the moment ('LIST') | 00:49 |
srichter | right | 00:49 |
srichter | I need to think about some good way to document this | 00:50 |
gintas | no big deal, we can add a list (or a method) as an attribute for the traverser | 00:50 |
gintas | you should discern between 'container' traversers (dynamic) and 'component' traversers (static) though | 00:50 |
srichter | mmhhh, this will be tough for the same reason | 00:51 |
srichter | unless I check that the for attribute inherits IReadContainer | 00:52 |
gintas | or you can make these 'static' traversers (e.g., PersonHTTPTraverser) implement some interface | 00:53 |
gintas | e.g., 'StaticTraverser' (bad name, I know) | 00:53 |
gintas | which would have a method 'listChildren()' or something like that | 00:53 |
srichter | yeah, but first I want to try not imposing new conventions | 00:54 |
srichter | I want to impose only the most necessary ones | 00:54 |
gintas | sure | 00:54 |
srichter | darn, this is almost hopeless | 00:55 |
povbot | /svn/commits: * gintas committed revision 4563: | 00:57 |
povbot | /svn/commits: Cosmetic fixes. | 00:57 |
gintas | can't resist ;) | 00:58 |
srichter | ok, I agree with your following assessments: | 00:58 |
srichter | - we need to differentiate between static and dynamic traversers | 00:59 |
srichter | - we need some method or better property that tells us the output interface of the traversable names | 01:00 |
srichter | <list done> | 01:01 |
srichter | I think with any view deriving from sb.app.rest.View we can do something special as well | 01:02 |
gintas | possibly | 01:03 |
gintas | btw, I think you're doing a great job on these devmode niceties in general | 01:03 |
gintas | I'm looking forward to the profiler in particular ;) | 01:04 |
srichter | thanks | 01:13 |
srichter | I am still not sure what I am going to do with the profiler | 01:14 |
srichter | Tom also has not officially assigned the task to me | 01:14 |
srichter | it just came up in a later discussion | 01:14 |
srichter | gintas: why isn't there a POST for IPerson | 01:20 |
srichter | I guess PUT mainly is implemented for containers? | 01:22 |
gintas | yes | 01:24 |
gintas | in SB usually we use PUT when we know where we want the object | 01:25 |
gintas | i.e. PUT /container/object_id | 01:25 |
gintas | we use POST when we want the system to assign the id | 01:25 |
gintas | POST /container -> the object appears at /container/043 | 01:25 |
srichter | I see | 01:25 |
gintas | but PUT is not for containers, it's for the objects inside | 01:26 |
gintas | sorry | 01:26 |
gintas | yes, it's for containers | 01:26 |
srichter | sp why is there no post for simple objects, like IPerson? | 01:26 |
gintas | 1:30 AM, not thinking straight ;) | 01:26 |
gintas | probably because when you create a person you have to specify a username | 01:26 |
srichter | I know, but right now you ar ereally helpful :-) | 01:26 |
gintas | which means that you know where your 'person' object will end up | 01:27 |
gintas | so you might as well use PUT | 01:27 |
srichter | ok, so the PU for manipulating an IPerson is implemented in IPersonContainer | 01:27 |
gintas | in the case of a resource, you might want to say "I don't care what the id of this resource will be, just create one", then you POST and the server puts the object wherever it wants | 01:28 |
srichter | right | 01:28 |
srichter | so that's the reson simple objects usually do not have a POST or PUT | 01:28 |
srichter | since POST and PUT are usually called from the container | 01:29 |
gintas | yes | 01:29 |
srichter | so the sentence would be: in container POST data to simpleobj | 01:29 |
gintas | it's because a PUT may create a new object | 01:29 |
gintas | I'm not sure about POST | 01:29 |
srichter | but why not have a POST for IPerson then? | 01:30 |
gintas | because PUT is sufficient | 01:30 |
srichter | basically saying: POST IPerson --> change data (title, description) | 01:30 |
srichter | ok | 01:30 |
gintas | GET & PUT are simple, you only use POST when they are not sufficient | 01:30 |
srichter | ok, good to know | 01:30 |
gintas | I'd say 'sentences' are 'nouns' (URIs), 'verbs' (GET/POST/etc.) and data | 01:32 |
srichter | so really the synopsis for PUT is: | 01:32 |
gintas | so 'in foo POST bar' is not entirely correct, because it would seem to imply two 'nouns' | 01:32 |
srichter | PUT IPersonContainer/itemid | 01:32 |
gintas | I meant 'in foo POST bar to baz' | 01:32 |
gintas | yes, that's right | 01:33 |
srichter | so PUT is registered for IPersonContainer | 01:34 |
srichter | using app.PersonContainerView | 01:34 |
srichter | but I do not see where the method PUT is implemented in that view | 01:34 |
gintas | hmm, it's been a while since I did anything with REST | 01:37 |
gintas | oh | 01:38 |
gintas | look at ApplicationObjectFileFactory, I think | 01:38 |
srichter | ok, thanks | 01:38 |
gintas | PUTs are handled differently than GETs or POSTs, IIRC | 01:38 |
gintas | I can't remember how exactly | 01:39 |
gintas | looks like they involve adapters to FileFactory | 01:39 |
srichter | yeah, but how; this seems a bit like magic | 01:40 |
srichter | ok, somehow create() is called on GenericContainerView | 01:41 |
gintas | yep, there's some magic that I don't like much | 01:43 |
gintas | but the magic is in Zope 3 | 01:43 |
srichter | ok, there is no PUT at all in sb.app.rest | 01:45 |
gintas | look at the ZCML | 01:46 |
srichter | in fact in all of zope.app it is only in zope.app.http.put | 01:46 |
srichter | where? | 01:46 |
gintas | schoolbell.app.rest/configure.zcml | 01:47 |
gintas | there's a section for adapters related to PUT | 01:47 |
gintas | that might clear things up a bit | 01:47 |
srichter | ok, so the stuff that is interesting is in zope.app.http.put | 01:48 |
srichter | those are actually used | 01:48 |
srichter | I wonder whether I could just remove the PUT declaration in the sb configurataion | 01:49 |
gintas | that is likely | 01:51 |
gintas | it could have sneaked in when porting | 01:51 |
srichter | yep :-) | 01:52 |
srichter | okay, now that makes sense | 01:53 |
srichter | now there is no magic anymore :-) | 01:54 |
povbot | /svn/commits: * srichter committed revision 4564: | 01:55 |
povbot | /svn/commits: Implemented the Introspector view in devmode. Check it out; I think it could be useful. ;-) | 01:55 |
povbot | /svn/commits: I still owe you guys some ftests for this code. | 01:55 |
gintas | excellent | 01:55 |
gintas | does that mean that I can go to sleep now? ;) | 01:55 |
srichter | yes :-) | 01:55 |
srichter | thanks a whole lot! | 01:55 |
gintas | it's a pleasure having you onboard | 01:57 |
gintas | bye | 01:57 |
*** gintas has quit IRC | 01:57 | |
*** SteveA has quit IRC | 02:20 | |
*** pcardune has quit IRC | 03:48 | |
*** eldar has quit IRC | 04:05 | |
*** bskahan has joined #schooltool | 05:47 | |
*** bskahan has quit IRC | 05:50 | |
*** tvon has quit IRC | 06:30 | |
*** srichter has quit IRC | 06:30 | |
*** srichter has joined #schooltool | 06:33 | |
*** tvon has joined #schooltool | 06:49 | |
*** tvon has quit IRC | 07:24 | |
*** srichter has quit IRC | 07:24 | |
*** povbuildbot has quit IRC | 07:24 | |
*** auxesis has quit IRC | 07:24 | |
*** FarcePest has quit IRC | 07:24 | |
*** dman13 has quit IRC | 07:24 | |
*** Aiste has quit IRC | 07:24 | |
*** munkee has quit IRC | 07:24 | |
*** Ricey has quit IRC | 07:36 | |
*** tvon has joined #schooltool | 07:36 | |
*** srichter has joined #schooltool | 07:36 | |
*** FarcePest has joined #schooltool | 07:36 | |
*** dman13 has joined #schooltool | 07:36 | |
*** Aiste has joined #schooltool | 07:36 | |
*** povbuildbot has joined #schooltool | 07:36 | |
*** auxesis has joined #schooltool | 07:36 | |
*** munkee has joined #schooltool | 07:36 | |
*** Ricey_ has joined #schooltool | 07:36 | |
*** admp has joined #schooltool | 10:59 | |
*** tvon has quit IRC | 11:10 | |
*** tvon has joined #schooltool | 11:11 | |
*** jinty has joined #schooltool | 11:22 | |
povbot | /svn/commits: * jinty committed revision 4565: | 12:35 |
povbot | /svn/commits: Create a branch for my experiments packging schoolbell without a Zope3 external. | 12:35 |
*** th1a has joined #schooltool | 12:49 | |
*** ignas has joined #schooltool | 13:17 | |
jinty | hoi th1a | 13:31 |
th1a | Hi jinty. | 13:32 |
th1a | Are you back home? | 13:32 |
jinty | yep, got back yesterday | 13:32 |
jinty | now snowed under with work stuff left undone | 13:33 |
srichter | th1a: hi tom, I am going to do my morning boot sequence now then I will be available | 13:33 |
th1a | OK. The dev mode stuff looks good. | 13:34 |
th1a | I like the drop down menu. | 13:34 |
jinty | th1a: the debian directory, I would prefer to move it over to the zope-pkg-developers repository where other debian developers can get at it. I would then prefer to remove the one at source.schooltool.org | 13:35 |
jinty | but wanted to sound you out first | 13:36 |
th1a | Offhand, that sounds reasonable. | 13:36 |
th1a | Where is the zope-pkg-developers repository? | 13:37 |
* jinty is finding the url | 13:38 | |
jinty | here is an overview: http://debian.madduck.net/pkg-zope/wiki/Arch/Repos | 13:40 |
jinty | the basic idea is to maintain the zope related .deb packages in debian/ubuntu/... as a group rather than as individuals | 13:41 |
th1a | It wouldn't be hard to un-do this at some future point, if there was a good reason? | 13:42 |
jinty | it wouldn't be hard to un-delete the debian directory | 13:43 |
jinty | but future development on the packaging will not be under the schooltool contributers agreement | 13:44 |
jinty | if that matters | 13:44 |
th1a | I don't think it does if we're not paying you. | 13:48 |
jinty | the advantages of a volunteer;) | 13:49 |
*** ignas has quit IRC | 13:50 | |
jinty | hoi srichter: thanks for getting 3.1 more out the door!! | 13:56 |
*** ignas has joined #schooltool | 13:58 | |
*** bskahan has joined #schooltool | 14:03 | |
th1a | srichter: ayt? | 14:18 |
srichter | th1a: now I am | 14:23 |
srichter | jinty: you are welcome | 14:24 |
srichter | I think I will do 3.1c2 this weekend | 14:24 |
jinty | srichter: great! Could look and tell me if this is a schoolbell, zpkgtools or zope bug? http://issues.schooltool.org/issue320 | 14:28 |
srichter | jinty: this would take me a while to check out | 14:33 |
srichter | the SETUP.cfg makes no sense to me | 14:34 |
povbot | /svn/commits: * jinty committed revision 4566: | 14:34 |
povbot | /svn/commits: Remove the Zope 3 external. (Im on a branch) | 14:34 |
jinty | ouch! | 14:34 |
srichter | I need to see why and how the release works | 14:35 |
jinty | seemed strange to me that the installation from the tarball is different from the repository | 14:35 |
srichter | ahh, now I see | 14:35 |
srichter | it all makes sense | 14:35 |
* jinty chews his fingers in anticipation. | 14:36 | |
jinty | s/fingers/finger nails/ | 14:36 |
srichter | schooltool's reliance on zope.app.securitypolicy/securitypolicy.zcml is wrong | 14:36 |
srichter | for the SVN checkout it should use Zope3/securitypolicy.zcml and for the release etc/securitypolicy.zcml | 14:37 |
srichter | I think this is a clear case why it sucks so much that the site.zcml is a Python string in ST/SB | 14:38 |
jinty | etc/securitypolicy.zcml??? | 14:38 |
jinty | gets interesting for the standalone server | 14:38 |
srichter | yep | 14:38 |
jinty | prehaps it could be broken out into /etc/schooltool/site.zcml... | 14:39 |
srichter | yes | 14:40 |
jinty | but I'll just include securitypolicy in the nasty string for now to get things to work. | 14:40 |
srichter | yeah | 14:41 |
povbot | /svn/commits: * jinty committed revision 4567: | 14:46 |
povbot | /svn/commits: Assume zope is on the pythonpath. | 14:46 |
*** bskahan has quit IRC | 14:52 | |
*** gintas has joined #schooltool | 15:00 | |
srichter | gintas: hi | 15:00 |
srichter | gintas: I think we do not need to document the "dynamic" traversers, since they are always container item lookups | 15:01 |
srichter | there is no special traverser registered for it anyways. | 15:01 |
*** SteveA has joined #schooltool | 15:01 | |
srichter | the only non-container dynamic traverser I see is LinkTracerser, but it also does some sort of mapping lookup, so no big deal | 15:03 |
srichter | I'll call static traversers simple name traversers | 15:04 |
gintas | srichter, yep, makes sense | 15:04 |
*** bskahan has joined #schooltool | 15:13 | |
th1a | gintas: So we are requiring Python 2.4 in the release candidates? | 15:16 |
povbot | /svn/commits: * srichter committed revision 4568: | 15:17 |
povbot | /svn/commits: Added some documentation strings/ | 15:17 |
povbot | /svn/commits: * jinty committed revision 4569: | 15:18 |
povbot | /svn/commits: Remove zope3 from the tarball. | 15:18 |
povbot | /svn/commits: * srichter committed revision 4570: | 15:19 |
povbot | /svn/commits: Remove Profiler as an option, since it will not be implemented. It was suggested on IRC, but Tom and I just decided that we do not need it (at least for now). | 15:19 |
gintas | th1a, the .deb packages depend of python 2.4 | 15:34 |
gintas | python2.3 on windows is supported though | 15:34 |
gintas | if one really wants python2.3 on Debian, they can at the moment use the source | 15:35 |
gintas | I'll want to talk this over with Brian | 15:35 |
gintas | our deb package naming policy is not well suited either for supporting two versions | 15:37 |
gintas | we should have python2.3-schoolbell and python2.4-schoolbell instead of libschoolbell if we want to support both python versions | 15:37 |
povbot | /svn/commits: * jinty committed revision 4571: | 15:38 |
povbot | /svn/commits: Include zope.app.securitypolicy/securitypolicy.zcml in site definition, partial fix for http://issues.schooltool.org/issue320 | 15:38 |
gintas | jinty, are you there? | 15:38 |
jinty | gintas: I was planning a big overhall along with the zope3-lib stuff | 15:38 |
gintas | hi | 15:38 |
jinty | hi, was just having a look at the work you've done | 15:38 |
* jinty had to look for the debian dir | 15:39 | |
gintas | right | 15:39 |
gintas | I split Debian packaging off into a separate directory | 15:39 |
jinty | but thanks, you fixed a lot of things I was letting lapse... | 15:39 |
gintas | it was so much more work than I had expected ;) I'm really glad that you usually take care of this | 15:41 |
povbot | /svn/commits: * srichter committed revision 4572: | 15:41 |
povbot | /svn/commits: IHTTPRequest is not defined in zope.publisher.interfaces.browser but .http | 15:41 |
jinty | I see, I was speaking with th1a about moving ot to the pkg-zope-developers archive here: http://arch.debian.org/cgi-bin/archzoom.cgi/pkg-zope-developers@lists.alioth.debian.org--experimental?template=plain | 15:41 |
th1a | gintas: Do you think the error Philipp reported to the mailing list came from Python version issues? | 15:41 |
gintas | th1a, which error would that be? | 15:41 |
jinty | gintas: I know, the testing cycles get long and there are so many little things to get right. | 15:42 |
gintas | issue309? | 15:42 |
th1a | Ah... here's the title of the email: no luck with SchoolTool 0.11rc2 [WAS: Re: [schooltool] SchoolTool 0.11rc2 and SchoolBell 1.2rc2 Available] | 15:42 |
th1a | Oh, whoops. | 15:42 |
th1a | For some reason he just sent it to mgedmin and I. | 15:43 |
*** bskahan has quit IRC | 15:43 | |
th1a | Kinda annoying... | 15:43 |
th1a | I'll forward it. | 15:43 |
gintas | hmm, he doesn't trust me ;) | 15:43 |
th1a | He trusts me too much. | 15:43 |
gintas | if it's a serious problem, I'll try to get rc3 out today | 15:44 |
th1a | I just sent it to schooltool-dev. | 15:44 |
th1a | I'm not sure how serious it is. | 15:44 |
gintas | uuuh | 15:44 |
gintas | oh | 15:45 |
gintas | he has Zope 3 in his python2.3 site packages | 15:45 |
gintas | I wonder why that takes precedence over the local SchoolTool's Zope3 | 15:45 |
*** bskahan has joined #schooltool | 15:45 | |
th1a | Hm... That's jinty's bug. | 15:45 |
th1a | I mean, that he reported. | 15:45 |
th1a | Not that he caused. | 15:46 |
th1a | Right? | 15:46 |
gintas | not exactly | 15:46 |
gintas | jinty deleted the local zope 3 checkout, that's why the external one was being used | 15:47 |
srichter | maybe the path is not setup correctly | 15:47 |
srichter | don't append schoolbell's path but insert it at pos 0 | 15:47 |
*** alga has joined #SchoolTool | 15:49 | |
gintas | srichter, where is the path being appended to? | 15:49 |
gintas | Philipp didn't even say if he used Debian packages or the tarballs | 15:51 |
gintas | s/the // | 15:51 |
gintas | ok, it's probably not Debian packages | 15:52 |
srichter | gintas: I dunno where it is done, but it must be somewhere | 15:52 |
gintas | srichter, I grepped, and could not find anything | 15:53 |
gintas | could it be that Philipp tried to remove the local Zope 3 version? | 15:53 |
bskahan | untarring the rc2 tarballs gives me an error here | 15:53 |
srichter | no, it's done correctly | 15:53 |
srichter | see schoolbell-server.py | 15:53 |
gintas | srichter, I did, it uses an 'insert' | 15:53 |
bskahan | unexpected EOF error on gunzip and tar | 15:53 |
gintas | oh | 15:53 |
gintas | bskahan, which file? | 15:53 |
srichter | right, and it palces it at position 0, which is right | 15:54 |
bskahan | schooltool-0.11rc2/Zope3/src/zope/app/demo/pageletchooser/browser/configure.zcml | 15:54 |
bskahan | gzip: stdin: unexpected end of file | 15:54 |
bskahan | schooltool-0.11rc2/Zope3/src/zope/app/demo/pageletchooser/adapters.py | 15:54 |
gintas | I mean, which tarball | 15:54 |
bskahan | tar: Unexpected EOF in archive | 15:54 |
bskahan | tar: Unexpected EOF in archive | 15:54 |
bskahan | tar: Error is not recoverable: exiting now | 15:54 |
bskahan | rc2 | 15:54 |
jinty | check md5sums? | 15:54 |
bskahan | gintas: ignore me | 15:54 |
bskahan | my connetion choked in mid download | 15:54 |
bskahan | let me try again | 15:54 |
gintas | hmm, I forgot to upload md5sums | 15:55 |
bskahan | now that I have the whole package so to speak, it works fine | 15:56 |
bskahan | sorry about that, someday my connection will stay up for more than 5 minutes at a time | 15:56 |
*** bskahan has quit IRC | 15:58 | |
gintas | ;) | 15:58 |
jinty | LOL | 15:58 |
*** bskahan has joined #schooltool | 15:59 | |
srichter | bskahan: are you on encrypted wireless? | 16:08 |
bskahan | srichter: yes, why? | 16:08 |
srichter | I have noticed on my computer since I encrypted my wireless I am getting disconnected | 16:09 |
srichter | but only when I am idle for a few minutes | 16:09 |
th1a | The sitewide calendar seems to behave weirdly. | 16:09 |
srichter | this did not happen with non-encrypted wireless | 16:09 |
th1a | Although the main issue is that it should be accessible to unauthenticated users by default. | 16:09 |
gintas | jinty, what do you think about Debian packages depending on python2.4? | 16:10 |
bskahan | srichter: sadly I think its just my new connection, I've had WEP turned on for the last year without the sort of issues I'm having now | 16:10 |
srichter | I see | 16:10 |
jinty | gintas:now that sarge is out the way and 2.4 is in unstable, I have no issues. | 16:11 |
gintas | jinty, python2.4 is in Sarge too | 16:11 |
jinty | gintas: don't we also have a dependency on libxml2? | 16:12 |
gintas | we do | 16:12 |
gintas | why? | 16:12 |
jinty | I couldn't find a python2.4-libxml2 package in sarge | 16:13 |
gintas | oh | 16:13 |
gintas | that could be a problem | 16:13 |
gintas | but it seems to be there | 16:14 |
gintas | I just checked | 16:14 |
jinty | debian should be doing it's python2.3->2.4 transition shortly | 16:14 |
gintas | http://packages.debian.org/stable/python/python2.4-libxml2 | 16:14 |
jinty | wow, cool | 16:14 |
gintas | so, basically these .debs should run smoothly on sarge | 16:15 |
jinty | cool! | 16:15 |
gintas | you also mentioned skolelinux | 16:15 |
jinty | perhaps I should recant that mail... | 16:15 |
jinty | they will base off sarge | 16:16 |
gintas | oh | 16:16 |
gintas | so the dependency on python2.4 should not be a problem for them either, right? | 16:16 |
gintas | excellent | 16:16 |
* jinty looks for python2.4-xml, python2.4-reportlab in sarge | 16:18 | |
jinty | cool all there | 16:19 |
jinty | gintas: the future of the debian packages very much depends on how zope3-libs end up. So mostly I leave things as they are until then. | 16:25 |
povbot | /svn/commits: * jinty committed revision 4573: | 16:26 |
povbot | /svn/commits: Include zope.app.securitypolicy/securitypolicy.zcml in site definition, partial fix for http://issues.schooltool.org/issue320 | 16:26 |
povbot | /svn/commits: * jinty committed revision 4574: | 16:29 |
povbot | /svn/commits: Pull 4571 into my branch. | 16:29 |
gintas | by the way, jinty, I recently found out that I will be away on August 11th-15th | 16:30 |
gintas | could you take on the release manager's tasks during that time? | 16:32 |
gintas | most of the hard problems should be fixed by that time, I suppose | 16:33 |
gintas | perhaps some fixes might need to be backported, but it shouldn't amount to much work | 16:33 |
jinty | yep, should be ok. Let me know if there is anything I can do before as well... | 16:35 |
jinty | hmm if pov is paid for this, perhaps I can become a subcontractor... | 16:36 |
jinty | th1a: poke | 16:37 |
th1a | Eh? | 16:40 |
* jinty thinks about asking pov if he can subcontract the release management work;) | 16:41 | |
th1a | Well... we should work something out eventually. But today is a bad day to start thinking about it. | 16:42 |
* jinty misses being able to smile jokingly over irc | 16:44 | |
* th1a doesn't want to talk about money today. | 16:44 | |
alga | heh, we haven't had any subcontractors yet | 16:44 |
alga | :-) | 16:45 |
* th1a is an Indian subcontractor. | 16:45 | |
th1a | Tom doesn't really do anything. | 16:46 |
th1a | Just sends me 20% of his take. | 16:46 |
th1a | Bastard. | 16:46 |
th1a | Anyway... I'm wondering if we should create a special permission for the site-wide calendar. | 16:47 |
jinty | :) | 16:47 |
alga | I insist that sitewide calendar is meant to be public | 16:48 |
th1a | Because it isn't much use if unauthorized users can't see it. | 16:48 |
alga | we have plenty of means to create partially-accessable calendars | 16:48 |
alga | so, it should be zope.Public | 16:48 |
alga | OTOH, we might bump into some data protection issues in some jurisdictions | 16:49 |
th1a | I'm just worried that we'll end up having people set "View" permission on their root, which will be inherited in undesirable ways. | 16:49 |
th1a | The whole idea of shared calendaring bumps against data protection issues in some jursidictions. | 16:49 |
alga | right | 16:49 |
bskahan | isn't the content that might go into the calendar what is legally restricted | 16:52 |
povbot | /svn/commits: * jinty committed revision 4575: | 16:52 |
povbot | /svn/commits: Dont build Zope3 in the makefile. | 16:52 |
bskahan | so we're putting the onus of data protection on the person in charge of that calendar | 16:52 |
bskahan | similar to the printed school calendar | 16:53 |
bskahan | I haven't been able to prove it due to various issues, but I think the site calendar may be visible to unauthenticated visitors if your running schooltool inside zope3 rather than standalone | 16:54 |
th1a | alga and I just discussed this face to face. | 16:57 |
th1a | For this release, we just need to make sure we have the defaults right. | 16:57 |
* bskahan nods | 16:58 | |
bskahan | working on it now | 16:58 |
alga | actually it would be nice to have the security policy pluggable | 16:58 |
alga | so that switching the default to a paranoid one would be a configuration issue | 16:58 |
th1a | 'View' and 'View calendar' should be accessible to unauthenticated users, but we need to disallow those permissions where we don't want them to be inherited. | 16:58 |
th1a | That is, 'View' and 'View calendar' for top. | 16:59 |
th1a | Should be allowed. | 16:59 |
povbot | /svn/commits: * jinty committed revision 4576: | 17:03 |
povbot | /svn/commits: Include securitypolicy.zcml in ftesting.zcml. | 17:03 |
*** jinty has quit IRC | 17:13 | |
bskahan | alga: is there a reason it's better to use an event subscriber for setting the permission on the SchoolToolApplication object rather than doing it during __init__()? | 17:30 |
alga | permissions on what? | 17:32 |
alga | OK | 17:33 |
alga | I remembered | 17:33 |
alga | if you set permissions in __init__() | 17:33 |
alga | you need to set up permissions machinery in all unit tests that try to instantiate SchoolToolApplication() | 17:33 |
bskahan | ugh | 17:34 |
bskahan | thanks | 17:34 |
alga | np | 17:35 |
*** jinty has joined #schooltool | 17:36 | |
th1a | OK. I'm outta here. | 17:38 |
*** th1a has quit IRC | 17:39 | |
*** th1a has joined #schooltool | 17:41 | |
*** jinty has quit IRC | 17:50 | |
povbot | /svn/commits: * jinty committed revision 4577: | 18:09 |
povbot | /svn/commits: port 4576 to my branch. | 18:09 |
povbot | /svn/commits: * jinty committed revision 4578: | 18:09 |
povbot | /svn/commits: port 4576 to schooltool | 18:09 |
srichter | gintas: the DELETE view configurations for the containers also seemed superfluous | 18:19 |
srichter | I am surprised they did not cause the system to fail | 18:19 |
gintas | interesting | 18:19 |
srichter | but I finally understand how everything works | 18:26 |
srichter | see zope.app.publication.http | 18:27 |
srichter | HTTPPublication.callObject() | 18:27 |
srichter | though GET seems to be special | 18:29 |
srichter | ah, no, the HTTPPublication is specific to pure HTTP calls | 18:31 |
srichter | I see, very clever | 18:31 |
srichter | DELETE, PUT, and OPTION is provided for all interfaces | 18:32 |
srichter | but GET and POST have to be implemented separately | 18:33 |
povbot | /svn/commits: * bskahan committed revision 4579: | 18:55 |
povbot | /svn/commits: Set view and viewCalendar permissions on SchooltoolApplication. Explicitly deny view and viewCalendar on persons, groups, sections, and courses containers. Intentionally leaving out levels because this fix needs to be ported to the 0.11 branch. | 18:55 |
povbot | /svn/commits: should fix issue325 | 18:55 |
srichter | wow, documenting the REST API is really tough | 18:57 |
srichter | there's definitely a bit of magic going on (though I can see through the trick) | 18:57 |
alga | I had an impression that we're the only ones using plain zope.publisher.http views | 19:50 |
alga | thy're quite unwieldy and dusty | 19:51 |
srichter | alga: probably, why do you find them unwieldly and dusty? | 19:55 |
alga | I don't remember the particular details, but I had that feeling when approaching RESTive views for the first time | 20:12 |
alga | e.g., HEAD is not implemented | 20:12 |
alga | sorry, I have to run | 20:12 |
*** alga has quit IRC | 20:12 | |
ignas | srichter, well - marius did a lot of magic to make "Method not implemented" work | 20:16 |
ignas | and a lot of RESTive interface code is mine so the architecture might look err ... duno ... strange ;) | 20:17 |
srichter | :-) | 20:17 |
ignas | i wanted to keep code duplication as low as i can | 20:17 |
srichter | right, that's a noble goal | 20:17 |
srichter | actually it is not that bad | 20:17 |
srichter | I probably have to create an interface for traversers, so th edocs can be better | 20:18 |
srichter | I need to be able to know to what object a name gets traversed to | 20:18 |
srichter | (if possible) | 20:18 |
srichter | the difficulty of documenting comes mainly from zope.app.http | 20:20 |
srichter | the problem is that the PUT and DELETE depend on the parent of the traversed object | 20:20 |
srichter | so I have to figure out what parents are possible and then look up the view | 20:21 |
ignas | oh | 20:21 |
ignas | and how you solved "PersonHTTPTraverser" | 20:21 |
srichter | is that a question? | 20:22 |
ignas | yes | 20:22 |
ignas | because that one looks kind of difficult for automatic traversing :/ | 20:23 |
srichter | by implementing a new interface that allows us to discover the traversable names | 20:23 |
ignas | oh | 20:24 |
srichter | something like INameTraverser or so | 20:24 |
srichter | we can use that later for the actual implementation too | 20:24 |
srichter | it could be as easy as specifying a mapping from 'name' to factory | 20:25 |
srichter | ignas: did you know that Zope PUT supports extension recognition for creating files? | 21:27 |
srichter | because I think it might make you calendar ICS and VFB import/export easier. | 21:27 |
*** eldar has joined #schooltool | 21:29 | |
eldar | hi | 21:30 |
eldar | anyone here? | 21:30 |
eldar | i got a quick question | 21:30 |
ignas | give it to me :) | 21:52 |
ignas | srichter, still there ? | 21:53 |
srichter | yep | 22:00 |
ignas | a sec | 22:04 |
ignas | http://issues.schooltool.org/issue222 | 22:11 |
ignas | is it worth proposing something like the patch i have posted in Zope mailing list ? | 22:11 |
ignas | just thought i'd ask because you are working with the code around the places at the moment ... | 22:12 |
srichter | still reading | 22:17 |
srichter | what does it releate to? | 22:17 |
ignas | well you mentioned "extension recognition" | 22:18 |
srichter | yes | 22:18 |
ignas | and that reminded me the issue of having no way to access "charset" while processing posted/put data | 22:18 |
ignas | because you can't register a factory that takes whole request ... | 22:19 |
ignas | so why not first try geting a more specific factory (if possible) and fall back to the old mode of operation (to support old style FileFactories) | 22:19 |
ignas | registering file factory for an Object + Request instead of just plain object ... | 22:20 |
ignas | sorry if that's too OT at the moment | 22:20 |
srichter | ok, I think the file factory and write file adapter shoud grow methods to deal with the encoding | 22:20 |
*** FarcePest has quit IRC | 22:20 | |
ignas | i can keep it in stack for a bit longer if you have no time ... | 22:20 |
srichter | actually I would be okay, if they become views | 22:21 |
srichter | though you have to provide BBB | 22:21 |
srichter | I have no time right now to look at this | 22:21 |
srichter | but put it in the Z3 collector | 22:22 |
ignas | ok | 22:22 |
*** ignas has quit IRC | 22:42 | |
*** bskahan has quit IRC | 22:44 | |
*** tvon has quit IRC | 22:45 | |
*** tvon has joined #schooltool | 23:09 | |
*** Aiste has quit IRC | 23:10 | |
*** Aiste has joined #schooltool | 23:39 | |
*** gintas has quit IRC | 23:47 |
Generated by irclog2html.py 2.15.1 by Marius Gedminas - find it at mg.pov.lt!