| *** fredvd has joined #zope | 00:01 | |
| betabug | rostayob: your paste looks like it's something for #pyramid, not #zope | 00:05 |
|---|---|---|
| *** hever has joined #zope | 00:13 | |
| *** TresEquis has quit IRC | 00:21 | |
| *** slackrunner has quit IRC | 00:50 | |
| *** redir has joined #zope | 00:51 | |
| *** ccomb has quit IRC | 01:04 | |
| *** menesis has quit IRC | 01:14 | |
| *** sp0cksbeard has quit IRC | 01:22 | |
| *** mcdonc has quit IRC | 01:24 | |
| *** benji has quit IRC | 01:46 | |
| *** m8 has quit IRC | 01:54 | |
| *** River_Rat has joined #zope | 02:00 | |
| *** RiverRat has quit IRC | 02:02 | |
| *** Vejeta has quit IRC | 02:03 | |
| *** Vejeta has joined #zope | 02:05 | |
| *** River_Rat is now known as RiverRat | 02:08 | |
| CIA-107 | jinty * r121795 zope.testbrowser/ (CHANGES.txt setup.py): prepare release | 02:12 |
| CIA-107 | jinty * r121796 /zope.testbrowser/tags/4.0.2: Tagging 4.0.2 | 02:12 |
| CIA-107 | jinty * r121797 zope.testbrowser/ (CHANGES.txt setup.py): back to development | 02:12 |
| CIA-107 | jim jim-python-btrees * r121798 ZODB/ (13 files in 3 dirs): checkpoint | 02:12 |
| CIA-107 | janwijbrand * r121799 megrok.login/ (10 files in 2 dirs): use groktoolkit trunk versions, port to zope.testbrowser, remove z3c.testsetup dependency | 02:12 |
| CIA-107 | janwijbrand * r121800 megrok.login/src/megrok/login/tests/ (strict.py simple.py autoregister.py unset.py customlogin.py): remove obsolete z3c.testsetup markers | 02:12 |
| CIA-107 | janwijbrand * r121801 megrok.login/ (/bootstrap.py /src .): update bootstrap.py | 02:12 |
| CIA-107 | janwijbrand * r121802 megrok.login/CHANGES.txt: update changelog | 02:12 |
| CIA-107 | janwijbrand * r121803 megrok.login/setup.py: this will not be a mere bugfix release | 02:12 |
| CIA-107 | jfroche * r121804 /Products.GenericSetup/branches/localutility-with-nested-path: prepare | 02:12 |
| CIA-107 | jfroche localutility-with-nested-path * r121805 Products.GenericSetup/Products/GenericSetup/components.py: enable support for nested local utilities | 02:12 |
| CIA-107 | janwijbrand * r121806 /groktoolkit/branches/jw-integrate-megrok.login-megrok.chameleon: Integrate megrok.login and megrok.chameleon | 02:12 |
| CIA-107 | janwijbrand jw-integrate-megrok.login-megrok.chameleon * r121807 groktoolkit/ (grok.cfg buildout.cfg): integrate megrok.login and megrok.chameleon. megrok.login needs a checkout still, as its fixes are not yet released | 02:12 |
| *** srichter has joined #zope | 02:16 | |
| *** rostayob has left #zope | 02:19 | |
| *** MrTango has quit IRC | 02:29 | |
| *** tiwula has quit IRC | 02:32 | |
| *** J1m has quit IRC | 02:36 | |
| *** srichter has quit IRC | 02:45 | |
| *** sobczyk has joined #zope | 02:48 | |
| *** srichter has joined #zope | 02:53 | |
| *** daMaestro has quit IRC | 03:04 | |
| *** alga has joined #zope | 03:06 | |
| sobczyk | is it possible to mix storage backends in zope3? (ie. RDBMS, ZODB, LDAP) | 03:06 |
| *** Spanktar has quit IRC | 03:09 | |
| *** hever has quit IRC | 03:10 | |
| *** Vejeta has quit IRC | 03:26 | |
| *** John[a] has joined #zope | 03:39 | |
| *** alga has quit IRC | 03:50 | |
| *** astoon has quit IRC | 03:51 | |
| *** John[a] has quit IRC | 04:23 | |
| *** mcdonc has joined #zope | 04:35 | |
| *** CIA-107 has quit IRC | 05:09 | |
| *** webmaven has quit IRC | 05:25 | |
| *** CIA-85 has joined #zope | 05:33 | |
| *** srichter has quit IRC | 06:05 | |
| *** r0ver has joined #zope | 06:38 | |
| r0ver | hello. I'm getting a search result using zope.catalog's apply method. If the result is not empty that method gives a list of catalog ids', do you know how may i get the object using such id ? | 06:39 |
| *** tiwula has joined #zope | 06:43 | |
| r0ver | ok, found it: from zope import component ; from zope.intid.interfaces import IIntIds; uidutil = component.getUtility(IIntIds) ; uidutil.getObject( uid ) | 07:01 |
| *** moo has joined #zope | 07:07 | |
| *** moo is now known as Guest31661 | 07:08 | |
| *** espent has quit IRC | 07:08 | |
| *** moo-_- has quit IRC | 07:08 | |
| *** espent has joined #zope | 07:08 | |
| *** sm has quit IRC | 07:25 | |
| *** Vejeta has joined #zope | 07:27 | |
| *** Vejeta has joined #zope | 07:27 | |
| *** slackrunner has joined #zope | 07:41 | |
| *** tiwula has quit IRC | 08:21 | |
| *** fredvd has quit IRC | 08:31 | |
| *** menesis has joined #zope | 08:35 | |
| *** agroszer has joined #zope | 08:36 | |
| *** slackrunner has quit IRC | 08:47 | |
| *** wosc has joined #zope | 08:49 | |
| *** CIA-85 has quit IRC | 08:58 | |
| *** tisto has joined #zope | 09:05 | |
| *** mr_jolly has joined #zope | 09:10 | |
| *** yvl has quit IRC | 09:11 | |
| *** CIA-89 has joined #zope | 09:14 | |
| *** hever has joined #zope | 09:17 | |
| *** mr_jolly has quit IRC | 09:17 | |
| *** yvl has joined #zope | 09:28 | |
| *** tisto has quit IRC | 09:35 | |
| *** zagy has joined #zope | 09:37 | |
| *** slackrunner has joined #zope | 09:41 | |
| *** tisto has joined #zope | 09:41 | |
| *** alga has joined #zope | 09:46 | |
| *** goschtl has joined #zope | 09:57 | |
| *** Wu has joined #zope | 09:58 | |
| CIA-89 | yuppie * r121808 zopetoolkit/ztk-sources.cfg: - use ZODB/branches/3.10 to make the tests pass | 10:01 |
| *** Wu has quit IRC | 10:03 | |
| betabug | sobczyk: if you use different mount points, it should be no problem | 10:06 |
| *** planetzopebot has quit IRC | 10:08 | |
| *** planetzopebot has joined #zope | 10:08 | |
| *** Wu has joined #zope | 10:08 | |
| *** eperez has joined #zope | 10:22 | |
| *** ccomb has joined #zope | 10:25 | |
| *** toutpt has joined #zope | 10:32 | |
| *** webmaven has joined #zope | 10:35 | |
| *** MrTango has joined #zope | 10:35 | |
| *** slackrunner has quit IRC | 10:37 | |
| *** avoinea has joined #zope | 10:42 | |
| *** sylvain has joined #zope | 10:43 | |
| *** trustedsage has quit IRC | 10:51 | |
| *** trustedsage has joined #zope | 10:51 | |
| kosh | betabug: so how are things going? | 10:55 |
| betabug | hey kosh | 10:55 |
| betabug | fine, auite busy | 10:55 |
| betabug | haha | 10:56 |
| kosh | I created some cool code for jquery ui tabs, I created an alternate url with data-url="someotherurl" and when I generate the tabs I swap that url for the one in the href | 10:56 |
| betabug | and it's summer now - at least almost as hot as it gets | 10:56 |
| betabug | nice | 10:57 |
| kosh | that way if JS is off or if a search engine hits it will get a normal full url that has a full wrapper and everything | 10:57 |
| betabug | cool | 10:57 |
| kosh | but if a browser hits and loads the tabs the url will be swapped to one that does a page fragment | 10:57 |
| kosh | so I don't have to render the header, footer, other stuff and just return the fragment | 10:57 |
| kosh | I can also give the fragments a unique url so they cache very nicely :) | 10:57 |
| kosh | most of the js methods I looked at involved rendering the entire page and then selecting just the fragment you want as what you put in the tab | 10:58 |
| kosh | this method is VASTLY faster | 10:58 |
| betabug | yeah | 10:58 |
| kosh | so I am pretty happy with how it has turned out | 10:59 |
| kosh | I have been doing a lot to makes my pages faster via better caching | 11:00 |
| kosh | what I wish though is that html just had a feature so that any element could have a src | 11:00 |
| betabug | I fought a hard fight with that norwegian site the last few days | 11:00 |
| kosh | then you could just put a src for a div etc and it would be able to cache normally | 11:00 |
| kosh | I have gotten many sites down to 3 requests or so for a cached version | 11:01 |
| kosh | down from 30 or so for many of them | 11:01 |
| kosh | so pages load faster on additional pages and the server has lower load :) | 11:02 |
| kosh | which means that it responds faster | 11:02 |
| kosh | versioned urls are such a great thing | 11:02 |
| *** j-w has joined #zope | 11:08 | |
| *** webmaven has quit IRC | 11:08 | |
| *** menesis has quit IRC | 11:09 | |
| kosh | I wonder what it would take to build versioned urls into zope, probably not very hard | 11:11 |
| betabug | kosh: I thought you already had a product for that? | 11:11 |
| kosh | it is too bad that other systems don't do it, it makes it easy to do the right thing for making pages faster | 11:11 |
| kosh | yeah I do have a product for that | 11:11 |
| kosh | I was thinking more along the lines of making it so any container object in zope could generate a versioned url for an item in it | 11:11 |
| *** mr_jolly has joined #zope | 11:11 | |
| betabug | hmm, right | 11:12 |
| betabug | well, but that's one thing that would be easy to do with acquisition | 11:12 |
| kosh | it is just that if it is built into the containers then it would be possible to patch it in instead of a seperate product | 11:12 |
| kosh | which could get it accepted | 11:12 |
| *** menesis has joined #zope | 11:14 | |
| kosh | on one site a full load is 1.5 seconds but a cached load and subsequent pages are .5 seconds :) | 11:14 |
| kosh | what I have been trying to do is make tools so that when we build websites they are super cache friendly by default without any additional work needed to make that happen | 11:17 |
| kosh | if you require additional work then the work just does not get done | 11:17 |
| kosh | one site is sad, one of the tracking companies a customer of ours is using won't configure their servers to compress the data they send for the tracking script or do any kind of caching | 11:19 |
| *** menesis has quit IRC | 11:19 | |
| kosh | so on a cached page load that script is the #1 source of bandwidth usage and slowdowns | 11:19 |
| *** webmaven has joined #zope | 11:23 | |
| j-w | kosh: you mean for page resources? | 11:32 |
| j-w | like js and images etc.? | 11:33 |
| kosh | yeah | 11:33 |
| j-w | you might want to look at fanstatic | 11:33 |
| j-w | that does that + resource dependency management | 11:33 |
| kosh | I generate unique urls now for css, js, images, favicon | 11:33 |
| j-w | it is an evolution from zc.resourcelibrary and hurry.resource | 11:34 |
| j-w | it does bundling too | 11:34 |
| j-w | and work is on its way to facilitate compression/minification-like things | 11:35 |
| kosh | I do all compression in nginx already | 11:35 |
| kosh | hmm fanstatic looks like it is a lot more complex then what I need a lot more of a pain to integrate into what we do | 11:38 |
| kosh | I don't have anything resembling a single location that all images are stored | 11:38 |
| kosh | they are part of whatever the products etc are | 11:38 |
| kosh | and I have the urls so that they update whenever the object changes so no shift-reload on any of my stuff anymore anyways | 11:38 |
| kosh | with zope generating a versioned url is pretty easy, just use the bobobase_modification_time | 11:39 |
| kosh | it is an interesting library but it looks like it would require vastly more work for me to use something like that | 11:40 |
| j-w | kosh: you do not need a single location at all | 11:40 |
| j-w | you can just define the resources in the products they belong to, np | 11:40 |
| kosh | it mostly looks like a lot of work | 11:41 |
| j-w | and the shoft-reload-problem is *exactly* what is solves | 11:41 |
| kosh | I don't have that problem though | 11:41 |
| j-w | it doesn't too me :-) | 11:41 |
| j-w | anyway, I just wanted to point it out | 11:41 |
| j-w | to prevent double work | 11:41 |
| kosh | whenever a customer goes into the webpage and uploads a new image a new url is generated | 11:41 |
| j-w | choose to tools you like to use :-) | 11:41 |
| j-w | for enduser-controlled-images, fanstatic might not be so useful indeed | 11:44 |
| j-w | I thought you meant more "static" resources | 11:44 |
| kosh | well I consider user generated images to be static also since for all practical purposes they are | 11:44 |
| kosh | once they uplaod an image it is static until they upload another one | 11:44 |
| kosh | a versioned urls works great for that | 11:44 |
| kosh | but integrating that with fanstatic looks like a lot of work | 11:45 |
| kosh | there is no real good reason that uploading an image by the client should not get an indefinite url also that changes whenever the image does | 11:46 |
| kosh | it makes it very cache friendly and does not cause any issues and it also means you have no shift-reload problems ever while also having indefinite caching | 11:46 |
| *** mitchell`off is now known as mitchell` | 11:47 | |
| *** Ariel_Calzada has joined #zope | 11:49 | |
| *** digitalmortician has joined #zope | 11:51 | |
| *** digitalmortician has quit IRC | 11:52 | |
| *** digitalmortician has joined #zope | 12:00 | |
| *** gwik has quit IRC | 12:02 | |
| *** gwik has joined #zope | 12:02 | |
| *** slackrunner has joined #zope | 12:06 | |
| *** evilbungle has joined #zope | 12:14 | |
| CIA-89 | janwijbrand * r121809 megrok.login/ (4 files in 3 dirs): cleanups | 12:21 |
| *** Guest31661 is now known as Moo-_- | 12:25 | |
| *** TomBlockley has joined #zope | 12:34 | |
| *** teix has joined #zope | 12:46 | |
| *** digitalmortician has quit IRC | 12:55 | |
| *** TomBlockley has quit IRC | 12:57 | |
| *** menesis has joined #zope | 12:58 | |
| *** digitalmortician has joined #zope | 13:00 | |
| *** Ariel_Calzada has quit IRC | 13:02 | |
| *** slackrunner has quit IRC | 13:12 | |
| CIA-89 | janwijbrand * r121810 groktoolkit/grok.cfg: add megrok.chameleon to the GTK | 13:13 |
| CIA-89 | janwijbrand * r121811 grokproject/CHANGES.txt: amend changelog | 13:13 |
| *** alexpilz has joined #zope | 13:17 | |
| *** srichter has joined #zope | 13:21 | |
| *** toutpt has quit IRC | 13:27 | |
| *** ccomb has quit IRC | 13:32 | |
| *** Ariel_Calzada has joined #zope | 13:41 | |
| *** TomBlockley has joined #zope | 13:42 | |
| *** regebro has joined #zope | 13:46 | |
| *** yvl has quit IRC | 14:00 | |
| *** r0ver has left #zope | 14:02 | |
| *** j-w has quit IRC | 14:07 | |
| *** dayne has joined #zope | 14:09 | |
| *** tisto is now known as tisto|lunch | 14:10 | |
| *** yvl has joined #zope | 14:12 | |
| *** humanfromearth has joined #zope | 14:22 | |
| humanfromearth | hi, does anyone know any benchmark packages for Zope2? | 14:24 |
| kosh | what do you mean? | 14:32 |
| * lewellyn hands kosh some marshmallows | 14:32 | |
| kosh | stuff like ab, siege etc works on any web server | 14:33 |
| lewellyn | oh btw, you were mentioning caching earlier. which web server do you have sitting in front of zope? | 14:33 |
| kosh | lewellyn: I have nginx sitting in front of zope | 14:34 |
| kosh | also the caching I was talking about was client side caching | 14:34 |
| lewellyn | ah ok. | 14:34 |
| kosh | generate a versioned url and set an insane timeout on it | 14:34 |
| lewellyn | i've been having a hell of a time getting nginx to cache proxy responses :( | 14:34 |
| kosh | so instead of /css you do /ver_123141231/css and change the number whenever the css changes | 14:34 |
| lewellyn | i also have yet to figure out the magic of fastcgi with zope | 14:34 |
| kosh | I just use regular proxy to to zope no fastcgi, wsgi etc | 14:35 |
| lewellyn | yeah. my idea is to have expires times set 15 minutes in the future, so that's the longest something will go stale. | 14:35 |
| lewellyn | yeah. i'm trying to reduce overhead, so i was hoping to drag medusa out of the picture. | 14:35 |
| kosh | I have my images, files, js, css, and favicon set to cache forever now on most things | 14:35 |
| kosh | the url will just change if the content changes | 14:35 |
| *** Ariel_Calzada has quit IRC | 14:36 | |
| lewellyn | yeah. i'm not big on those urls. i'll stay with "go get some coffee and it'll update itself" ;) | 14:36 |
| kosh | those urls massively speed up the page and take me no effort to deal with | 14:36 |
| kosh | it also means when content changes the data immediately changes | 14:36 |
| lewellyn | but my big goal atm is to try to get zope to serve as little as possible | 14:37 |
| kosh | so if I change the css file everyone will see it instantly | 14:37 |
| lewellyn | which means getting nginx to actually cache the responses from zope | 14:37 |
| kosh | hmm my pages load in .5 seconds usually so zope does not seem to be a major source of speed issues | 14:37 |
| lewellyn | nice side effect is that by eating the cookies, it's not obviously zope. (i have little need for sessions and stuff, for this site) | 14:37 |
| kosh | most of the page load time was all the resources being loaded | 14:38 |
| lewellyn | well, i can only handle a dozen or so simultaneous requests on the home page. | 14:38 |
| kosh | so if you have 80 images on a page by default everyone one of those images will be checked and find out it has not changed | 14:38 |
| kosh | same with the css and javascript | 14:38 |
| lewellyn | which is an improvement over the 1-3 +/- we used to be at :P | 14:38 |
| kosh | having to generate that css and javascript also makes things slower | 14:38 |
| kosh | you can realy make zope far faster with client side caching | 14:39 |
| lewellyn | yeah. i want nginx to handle that aspect. | 14:39 |
| lewellyn | "i've checked the backend within 15 minutes for that. here. it's fresh enough." | 14:39 |
| kosh | not the same though | 14:39 |
| kosh | since the browser will make the request | 14:39 |
| kosh | and that will slow it down | 14:39 |
| lewellyn | yeah. but not as much as zope responding instead :) | 14:40 |
| lewellyn | loading it all from disk/ram is far faster than waking things up constantly | 14:40 |
| kosh | even if you make your server a million times faster the client is going to run slower then if it can cache the data | 14:41 |
| lewellyn | it can cache the data. most of the data's pretty static. | 14:41 |
| lewellyn | a 304 is far better than a 200 any day, and right now, that's far better than it's been at for the past like 8+ years | 14:41 |
| kosh | so how do you set the caching of your images so the browser when it comes back a week later does not load all that data again but still make it so that when the data changes they will see it? | 14:42 |
| kosh | 304 is still a large speed penalty | 14:42 |
| lewellyn | (i just discovered some days ago that it ALWAYS responded with a 200, period, and disabled caching.) | 14:42 |
| kosh | that does not seem right | 14:42 |
| kosh | the default image object in zope has done 304 for at least 6 years | 14:42 |
| lewellyn | 304 isn't a huge speed penalty when you're asking for a half dozen objects, thanks to pipelining. | 14:42 |
| lewellyn | yes. | 14:42 |
| lewellyn | there was a design decision made at some point | 14:43 |
| lewellyn | and i don't have the information available from back then to figure out why | 14:43 |
| humanfromearth | kosh: 'instead of /css you do /ver_123141231/css' - have you ever heard of etags? | 14:43 |
| lewellyn | of course, back then, a "back" button on every page was a good idea. | 14:43 |
| kosh | however a 304 still has a fairly major speed penalty | 14:43 |
| kosh | humanfromearth: the entire point is to make a unique url that will never change and is cached forever without any checking back from the browser, etags do not even remotely solve that problem | 14:44 |
| lewellyn | kosh: my testing from across the internet indicates that returning a bunch of 304s is faster than waiting for the javascript to initialize | 14:44 |
| kosh | an etag still means that a browser will revalidate | 14:44 |
| lewellyn | i.e. it's pretty much instant in ie 10 (which atm is the fastest browser i have available, amusingly) | 14:44 |
| lewellyn | i really need to pop open wireshark later to see what trickery they're doing to their page loads | 14:45 |
| kosh | lewellyn: ah I did some testing and used the chromium inspect feature and the network tab and watched how long various resoucres took to load vs having it cached locally with no connection at all | 14:45 |
| lewellyn | even TWITTER is pretty much instant to load | 14:45 |
| lewellyn | kosh: yeah. it's only a few ms for the 304s when pipelined. | 14:45 |
| kosh | not a clue about that, I have no way to test IE 10 | 14:46 |
| kosh | if your connection is low latency enough, if you have a cell connection or any kind of mobile device the penalty can be very high | 14:46 |
| CIA-89 | janwijbrand * r121812 grok/ (CHANGES.txt setup.py): Preparing release 1.7 | 14:46 |
| CIA-89 | janwijbrand * r121813 /grok/tags/1.7: Tagging 1.7 | 14:46 |
| CIA-89 | janwijbrand * r121814 grok/ (CHANGES.txt setup.py): Back to development: 1.8 | 14:46 |
| CIA-89 | janwijbrand * r121815 groktoolkit/grok.cfg: use grok-1.7 that correctly configures zope.app.wsgi and includes the global_adapter directive | 14:46 |
| CIA-89 | janwijbrand * r121816 grokproject/ (CHANGES.txt setup.py): Preparing release 2.6 | 14:46 |
| CIA-89 | janwijbrand * r121817 /grokproject/tags/2.6: Tagging 2.6 | 14:46 |
| CIA-89 | janwijbrand * r121818 grokproject/ (CHANGES.txt setup.py): Back to development: 2.7 | 14:46 |
| *** TomBlockley has quit IRC | 14:46 | |
| lewellyn | and the client has very clearly stated that if a resource is updated, it needs to never have the old version ever available again. | 14:46 |
| lewellyn | um. with my cell phone, it's only about 150ms to load the page of all 304's | 14:47 |
| kosh | my system does not have an old version ever available | 14:47 |
| lewellyn | 180 if i'm tethered via wifi to my phone, due to the crappy wifi router built in | 14:47 |
| kosh | but the client can upload a new image and everyone will see it instantly | 14:47 |
| kosh | no delay of any kind | 14:47 |
| kosh | and still forever caching | 14:47 |
| lewellyn | so somehow your pages still hit a server for a 304 somewhere | 14:48 |
| waldi | does nginx cache at all? it is a reverse proxy, but i miss the word cache from the description | 14:49 |
| waldi | i prefer vanish to do aggresive caching for zope applications | 14:50 |
| humanfromearth | kosh: you can use etags caching on the server side.. it is still better than changing the url's - url's are immutable imho | 14:50 |
| lewellyn | http://wiki.nginx.org/NginxHttpProxyModule | 14:50 |
| kosh | humanfromearth: that urls are immutable is the point | 14:50 |
| lewellyn | does varnish also serve static content? | 14:50 |
| kosh | humanfromearth: so that /ver_1231231231/css is not the same as /ver_456345645/css so since the url on the page changes the browser will request it | 14:50 |
| kosh | humanfromearth: etag caching requires checking back to the server so you have the round trip cost | 14:51 |
| lewellyn | and again, since practically everything does http pipelining these days, i don't see the savings being worth the obfuscation and extra development work. | 14:52 |
| kosh | the work was done once, it applied retroactively to every site I have made in the last 8 years | 14:52 |
| kosh | no code had to be changed on them | 14:52 |
| waldi | varnish is a caching reverse proxy. it have nothing to do with producing content | 14:53 |
| humanfromearth | so changing urls in your templates is better? I think it's 'saner' to let the server decide how to do this - not solve the problem in my templates | 14:53 |
| lewellyn | waldi: that makes it unsuitable as i use the front-ends for serving static content, as well. | 14:53 |
| lewellyn | i find that things like 100 meg pdfs are better stored on the filesystem than in the zodb *shrug* | 14:54 |
| kosh | for my testing I had 1.4 seconds for a site over the internet with 304s and .8 seconds with caching so that no hits come in at all | 14:54 |
| kosh | why would you store a blob like that in the zodb anyways, we do have blob support and that will just stream from the filesystem very efficiently | 14:54 |
| waldi | lewellyn: i have about 25GiB of data in zodb. 20 of them in for of blobs | 14:55 |
| *** Wu has quit IRC | 14:55 | |
| kosh | humanfromearth: why do you think I would manually change any of those urls? they are all auto generated | 14:55 |
| waldi | lewellyn: varnish is a proxy. noone said that it can only handle _one_ backend | 14:55 |
| kosh | humanfromearth: picture objects generate their img src lines so all you change is how it generates the src and it is done for all sites permanently | 14:55 |
| kosh | humanfromearth: there is no change at all for someone writing the site, they don't see any of it | 14:55 |
| kosh | I can't even imagine writing an img src line by hand | 14:56 |
| kosh | you would have to know the size of the image and everything | 14:56 |
| *** regebro has quit IRC | 14:57 | |
| kosh | with an image object when an image is uploaded I resize it if necessary, always recompress it and that object will generate the url so it always has the right height and width | 14:57 |
| kosh | even the regular zope image object generates the img src line | 14:58 |
| humanfromearth | so how do you integrate this with zope? | 14:58 |
| humanfromearth | I'm not aware of this functionality in it | 14:58 |
| humanfromearth | do you have an annotation for each ImageFile? | 14:59 |
| kosh | well it generates urls already inside images so I modified it with what I needed to version the urls | 14:59 |
| kosh | I also have a regular product that can be used to create versioned urls for any object | 14:59 |
| humanfromearth | I see | 14:59 |
| kosh | annotation? no idea what you mean for that | 14:59 |
| kosh | my objects have an OFS.Image.File in them or OFS.Image.Image in them and I change how I generate the url to those images, I use a regular product for css, js, favicons etc | 15:01 |
| humanfromearth | you're method is unorthodox and it's not very pretty, but I must admit that it would solve a lot of caching validation problems | 15:03 |
| kosh | why do you say it is not pretty? even google has a suggestion for that on one of their pagespeed sites | 15:03 |
| kosh | they heavily recommended versioned urls | 15:03 |
| betabug | even plone has been doing it for ages | 15:04 |
| kosh | since /css?ver=123142342 does not properly cache in all browsers but /ver_2342342/css will cache in everything | 15:04 |
| kosh | betabug: not for everything though, images it does not seem to do it for | 15:04 |
| humanfromearth | well it breaks the whole idea of what an url means | 15:04 |
| kosh | humanfromearth: how does it break the url? that url goes to that unique resource, if you want to serve a different resource you use a different url | 15:04 |
| kosh | you do the same thing with a CDN | 15:05 |
| kosh | if you delete data on a CDN and then add new data with the same name as the old entry you create a lot of problems | 15:05 |
| kosh | I don't get why this is seen as so strange and novel, it is very rare but then again any kind of competence in the web is very rare | 15:06 |
| humanfromearth | :) | 15:06 |
| humanfromearth | right.. | 15:06 |
| *** humanfromearth has left #zope | 15:06 | |
| kosh | on one page I tested a page full of 304s when from 1.6 seconds to .4 seconds with all pure cached and no hits | 15:07 |
| kosh | except the main html for the page which was not cached | 15:07 |
| kosh | betabug: it is very depressing that so few people understand this | 15:08 |
| betabug | dunno, I never cache my pages... if people are not prepared to wait for the page, then they don't deserve to see it!! | 15:10 |
| kosh | it makes the pages faster which does help with business | 15:10 |
| kosh | it also lowers server load | 15:11 |
| kosh | and my method of doing it was so simple | 15:11 |
| kosh | it is fully automatic | 15:11 |
| kosh | so it caches cleanly and does not require the dev to do squat | 15:11 |
| *** agroszer has quit IRC | 15:19 | |
| *** agroszer has joined #zope | 15:24 | |
| *** digitalmortician has quit IRC | 15:26 | |
| *** TomBlockley has joined #zope | 15:27 | |
| *** goschtl has quit IRC | 15:32 | |
| lewellyn | it'd surely break hotlinks to images, though. | 15:34 |
| kosh | acutally I leave the direct image links alone so they will still work they just won't cache forever | 15:36 |
| kosh | so this functions as a pure additional system | 15:36 |
| kosh | so /css for instance will sitll work just not be cached forever like /ver_3214234234/css would same for images | 15:37 |
| lewellyn | so if someone right clicks to get the image url, it'll keep working? | 15:37 |
| kosh | if they just copy the image url they would get the versioned url and while that url will keep working depending on when people first hit that url they could easily get different images | 15:38 |
| kosh | however I have no reason to encourage people to use my sites to host images on their sites | 15:38 |
| lewellyn | well, in this case, marketing includes site images in their emails | 15:38 |
| kosh | the problem would be if a browser sees that url and they have never seen it before they will request an image if that image is later changed the browser would not check again | 15:39 |
| lewellyn | and training marketing people to remember an extra step beyond what's obvious is bad :P | 15:39 |
| lewellyn | yeah. that'd be unacceptable in this case... | 15:39 |
| kosh | if you are sending out marketing information you would not want to send out image links that are changing quickly anyways | 15:39 |
| *** digitalmortician has joined #zope | 15:40 | |
| lewellyn | since more than once there's been an "oh shit" where art assets had to be reuploaded just after the email was sent | 15:40 |
| kosh | so you would have an image on the site and send out a link to it in your emails and then change that image during the marketing campaign? | 15:40 |
| kosh | that seems like a very silly thing to do | 15:40 |
| lewellyn | like a package mockup missing the ESRB RP logo, for instance. | 15:40 |
| kosh | however none of our customers uses the front end to get information like that, they use the backend | 15:40 |
| kosh | and the backend would give them a non versioned url which would do exactly what you want | 15:41 |
| lewellyn | and in this case, there's no reason for most of the employees to see the backend. | 15:41 |
| lewellyn | sure most have logins and i encourage them to log in to fix typos and stuff. but most of them have zero need to. | 15:42 |
| lewellyn | (official policy is just short of "have a meeting about it" whenever something is amiss, even an obvious typo. as an outsider, i can foster dissent... ;) ) | 15:42 |
| kosh | the official policy for most companies I have worked with that want to put images in emails and things like that is to put the file up on s3 and use that url | 15:44 |
| lewellyn | they like control *shrug* | 15:46 |
| kosh | and them uploading it to their s3 account on amazon would not be control? | 15:47 |
| kosh | while also making those images in the emails load faster | 15:47 |
| lewellyn | well, it'd be extra steps to correct one of those "oh shit" things | 15:49 |
| *** ccomb has joined #zope | 15:50 | |
| kosh | some of our customers started finding that html emails have just not been getting through so what they have been doing instead is sending a much simpler email with a link to the website and then that always works | 15:51 |
| kosh | and it was far less likely to be blocked as spam | 15:51 |
| lewellyn | in this case, customers complain if the email is late. it's VERY opt in | 15:52 |
| lewellyn | so being flagged as spam isn't a concern | 15:52 |
| *** TomBlockley has quit IRC | 15:53 | |
| lewellyn | (and the emails are much more "legit looking" than the average mass mail, due to an accident of history) | 15:53 |
| kosh | the emails our customers are sending are very opt in also | 15:53 |
| kosh | but it doesn't matter how legit something is with everyone running spam filters and false positives not being worth looking at | 15:53 |
| lewellyn | that's the thing. an accident of history has these emails not triggering most spam filters. every now and again, they have to tell someone to "add the address to safe senders" | 15:55 |
| *** J1m has joined #zope | 16:03 | |
| *** srichter has quit IRC | 16:20 | |
| *** sp0cksbeard has joined #zope | 16:24 | |
| *** shastry_ has joined #zope | 16:26 | |
| *** srichter has joined #zope | 16:26 | |
| *** shastry has quit IRC | 16:29 | |
| *** dayne has quit IRC | 16:42 | |
| *** davisagli has quit IRC | 16:45 | |
| *** davisagli has joined #zope | 16:46 | |
| *** TomBlockley has joined #zope | 16:55 | |
| *** regebro has joined #zope | 17:05 | |
| *** regebro has quit IRC | 17:13 | |
| *** redir has quit IRC | 17:14 | |
| *** pjfd4 has joined #zope | 17:33 | |
| *** Wu has joined #zope | 17:35 | |
| *** tisto|lunch is now known as tisto | 17:40 | |
| *** alga has quit IRC | 17:40 | |
| *** agroszer has quit IRC | 17:44 | |
| *** pjfd2 has joined #zope | 17:53 | |
| *** sm has joined #zope | 17:55 | |
| *** pjfd4 has quit IRC | 17:56 | |
| *** digitalmortician has quit IRC | 18:04 | |
| *** daMaestro has joined #zope | 18:13 | |
| *** alvaro_o has joined #zope | 18:16 | |
| *** mitchell` is now known as mitchell`off | 18:19 | |
| *** alvaro_o has quit IRC | 18:21 | |
| *** wosc has quit IRC | 18:24 | |
| *** webmaven has quit IRC | 18:24 | |
| *** sylvain has quit IRC | 18:35 | |
| *** alexpilz has quit IRC | 18:36 | |
| *** avoinea has left #zope | 18:40 | |
| *** TomBlockley has quit IRC | 18:57 | |
| *** mgedmin has quit IRC | 18:57 | |
| *** tiwula has joined #zope | 18:58 | |
| *** redir has joined #zope | 18:58 | |
| *** mgedmin_ has joined #zope | 19:01 | |
| *** mgedmin_ has quit IRC | 19:09 | |
| *** mgedmin_ has joined #zope | 19:09 | |
| *** TomBlockley has joined #zope | 19:09 | |
| *** alexpilz has joined #zope | 19:14 | |
| *** tisto has quit IRC | 19:15 | |
| *** pjfd4 has joined #zope | 19:21 | |
| *** pjfd2 has quit IRC | 19:23 | |
| *** pjfd2 has joined #zope | 19:23 | |
| CIA-89 | tseaver * r121819 zope.interface/ (4 files in 3 dirs): | 19:24 |
| CIA-89 | Correct comparison of interfaces from different modules but with the same name. | 19:24 |
| CIA-89 | Fixes LP #570942. | 19:24 |
| CIA-89 | tseaver * r121820 zope.interface/ (CHANGES.txt setup.py): Prep 3.6.3 release. | 19:24 |
| CIA-89 | tseaver * r121821 /zope.interface/tags/3.6.3: Tag 3.6.3 release. | 19:24 |
| CIA-89 | tseaver * r121822 zope.interface/ (CHANGES.txt setup.py): svb | 19:24 |
| _mup_ | Bug #570942: InterfaceClass __cmp method obtains module name incorrectly <zope.interface:Fix Released> < https://launchpad.net/bugs/570942 > | 19:24 |
| *** Spanktar has joined #zope | 19:24 | |
| *** pjfd4 has quit IRC | 19:25 | |
| *** digitalmortician has joined #zope | 19:28 | |
| *** pjfd2 has quit IRC | 19:29 | |
| *** pjfd4 has joined #zope | 19:30 | |
| *** eperez has quit IRC | 19:33 | |
| *** pjfd4 has quit IRC | 19:39 | |
| *** alga has joined #zope | 19:41 | |
| *** menesis has quit IRC | 19:57 | |
| *** benji has joined #zope | 20:03 | |
| *** agroszer has joined #zope | 20:07 | |
| *** agroszer has quit IRC | 20:18 | |
| *** alga has quit IRC | 20:18 | |
| *** alga has joined #zope | 20:19 | |
| *** Wu has quit IRC | 20:21 | |
| *** mgedmin_ has quit IRC | 20:24 | |
| *** mr_jolly has quit IRC | 20:24 | |
| *** f10w has quit IRC | 20:24 | |
| *** mgedmin_ has joined #zope | 20:25 | |
| *** mr_jolly has joined #zope | 20:25 | |
| *** f10w has joined #zope | 20:25 | |
| *** evilbungle has quit IRC | 20:40 | |
| *** menesis has joined #zope | 20:41 | |
| *** ccomb has quit IRC | 21:26 | |
| *** m8 has joined #zope | 21:30 | |
| *** alexpilz1 has joined #zope | 21:39 | |
| *** evilbungle has joined #zope | 21:42 | |
| *** alexpilz has quit IRC | 21:42 | |
| *** alexpilz1 has quit IRC | 21:58 | |
| *** alexpilz has joined #zope | 21:59 | |
| *** supton has quit IRC | 22:27 | |
| *** teix has left #zope | 22:33 | |
| *** srichter has quit IRC | 22:48 | |
| *** zentraedi has joined #zope | 22:53 | |
| zentraedi | Hi everyone! | 22:54 |
| zentraedi | I was trying to install Cyn.in and got this error | 22:57 |
| zentraedi | http://paste.lisp.org/display/122291 | 22:58 |
| *** srichter has joined #zope | 23:41 | |
Generated by irclog2html.py 2.15.1 by Marius Gedminas - find it at mg.pov.lt!