seaside September 2009

seaside@lists.squeakfoundation.org

64 participants
72 discussions

RE: iCal to Drupal requires Content-Encoding: gzip
by bobn＠rogers.com 22 Sep '09

22 Sep '09

>Try: >SeasideHttpWriteHandler useGZipTransfer: true. ... >Tamara Kogan >Smalltalk development, >Cincom Systems Thanks. I was trying to set it in the context of a single WAResponse; I didn't think of changing the class value. Bob

2 1

RE: iCal to Drupal requires Content-Encoding: gzip
by bobn＠rogers.com 22 Sep '09

22 Sep '09

>Boris >Quick search reveals something called #useGZipTransfer and >#useGZipTransfer:, perhaps you could just set that property on a Seaside >adaptor? If not, Apache proxying your Seaside server can do compression >for you (you may need to turn off HTTP chunking of responses). Our production Seaside is proxied by Apache, but for testing we just use Seaside server. I did turn off chuncking (wget was having issues with it on). I did see how #useGZipTransfer was referenced, but I don't understand how to set it. How do you set #useGZipTransfer: to true in a Seaside adaptor? Thanks, Bob

2 1

RE: iCal to Drupal requires Content-Encoding: gzip
by bobn＠rogers.com 22 Sep '09

22 Sep '09

>Boris, >By the way, it might be easier to compare text files obtained with curl, >curl -iL http://www.google.com > google.txt >curl -iL http://www.microsoft.com > microsoft.txt Yes, this does show the Content-Dispostion difference. Google data is correctly in-lined. Our data has the <!DOCTYPE hmtl... header. Sounds like I need to understand how to properly answer the iCal datal. I can work on that. Thanks again, Bob

1 0

iCal to Drupal requires Content-Encoding: gzip
by Bob N. 21 Sep '09

21 Sep '09

Hello, We're trying to provide an iCal feed from Seaside (on VW) to Drupal. The Drupal use of the feed can be tested using a Google calendar iCal feed, and it works fine. We're able to produce a simple iCal document as well, but Drupal does not accept it. Both the Google and our Seaside iCal feeds download fine with just the browser. The one big difference we can see in the header is that the Google contains 'Content-Encoding: gzip' and ours does not. I have not be able to determine how we can properly provide the gzip compressed version of the content. Has anyone done an iCal feed from Seaside to Drupal? Or, how can I get the gzip properly to be properly supported in my data source? Thanks for any help, Bob Nemec Cherniak Software ---- Here are some details... Documentation on iCal in Drupal ... http://drupal.org/node/341716 http://www.drupalove.com/drupal-video/ical-events-nodes I'm packaging the response with... (aFilename=events.ics, aContent is a read stream on the string) WAResponse new contentType: 'text/calendar;charset=utf-8'; doNotCache; headerAt: 'Content-Disposition' put: 'attachment; filename="' , aFileName , '"'; headerAt: 'Content-length' put: aContents size printString; contents: aContents; yourself It looks like SeasideHttpWriteHandler>>prepareStream:forMessageBody: will do the compression with GZipWriteStream if useGZipTransfer = true, but I can't find a way to propagate that setting, and so far none of my attempts at hacking it are working. I had hoped something as simple as adding #headerAt: 'Content-Encoding' put: 'gzip' would work, but that just creates an invalid file. To see the header contents, we use the Live HTTP headers Firefox plug in. This is the Google header... http://www.google.com/calendar/ical/<our test calendar ics file> GET /calendar/ical/<our test calendar ics file> HTTP/1.1 Host: www.google.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3 (.NET CLR 3.5.30729) Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-us,en;q=0.5 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Cookie: <some cookie data> HTTP/1.x 200 OK Content-Type: text/calendar; charset=UTF-8 Cache-Control: no-cache, no-store, max-age=0, must-revalidate Pragma: no-cache Expires: Fri, 01 Jan 1990 00:00:00 GMT Date: Mon, 21 Sep 2009 00:14:03 GMT Content-Encoding: gzip X-Content-Type-Options: nosniff X-Frame-Options: SAMEORIGIN Content-Length: 3421 Server: GFE/2.0 ---------------------------------------------------------- And this is our Seaside header... http://localhost:48199/seaside/Test GET /seaside/Test HTTP/1.1 Host: localhost:48199 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3 (.NET CLR 3.5.30729) Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-us,en;q=0.5 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Referer: http://localhost:48199/seaside Cookie: <some cookie data> HTTP/1.x 200 OK Expires: Wed, 11 Jun 1980 08:00:00 -0400 Cache-Control: no-cache,must-revalidate Pragma: no-cache Content-Disposition: attachment;filename=events.ics Content-Type: text/calendar;charset=utf-8 Content-Length: 10944 ---------------------------------------------------------- WAKomCompressed>>convertResponse: aResponse | response gzip stream | response := super convertResponse: aResponse. response fieldAt: 'Content-Encoding' put: 'gzip'. gzip := GZipWriteStream on: (stream := RWBinaryOrTextStream on: ''). gzip nextPutAll: aResponse contents contents; close. ^ response contents: stream reset

1 0

iCal to Drupal requires Content-Encoding: gzip
by Bob Nemec 21 Sep '09

21 Sep '09

Hello, We're trying to provide an iCal feed from Seaside (on VW) to Drupal. The Drupal use of the feed can be tested using a Google calendar iCal feed, and it works fine. We're able to produce a simple iCal document as well, but Drupal does not accept it. Both the Google and our Seaside iCal feeds download fine with just the browser. The one big difference we can see in the header is that the Google contains 'Content-Encoding: gzip' and ours does not. I have not be able to determine how we can properly provide the gzip compressed version of the content. Has anyone done an iCal feed from Seaside to Drupal? Or, how can I get the gzip properly to be properly supported in my data source? Thanks for any help, Bob Nemec Cherniak Software ---- Here are some details... Documentation on iCal in Drupal ... http://drupal.org/node/341716 http://www.drupalove.com/drupal-video/ical-events-nodes I'm packaging the response with... (aFilename=events.ics, aContent is a read stream on the string) WAResponse new contentType: 'text/calendar;charset=utf-8'; doNotCache; headerAt: 'Content-Disposition' put: 'attachment; filename="' , aFileName , '"'; headerAt: 'Content-length' put: aContents size printString; contents: aContents; yourself It looks like SeasideHttpWriteHandler>>prepareStream:forMessageBody: will do the compression with GZipWriteStream if useGZipTransfer = true, but I can't find a way to propagate that setting, and so far none of my attempts at hacking it are working. I had hoped something as simple as adding #headerAt: 'Content-Encoding' put: 'gzip' would work, but that just creates an invalid file. To see the header contents, we use the Live HTTP headers Firefox plug in. This is the Google header... http://www.google.com/calendar/ical/<our test calendar ics file> GET /calendar/ical/<our test calendar ics file> HTTP/1.1 Host: www.google.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3 (.NET CLR 3.5.30729) Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-us,en;q=0.5 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Cookie: <some cookie data> HTTP/1.x 200 OK Content-Type: text/calendar; charset=UTF-8 Cache-Control: no-cache, no-store, max-age=0, must-revalidate Pragma: no-cache Expires: Fri, 01 Jan 1990 00:00:00 GMT Date: Mon, 21 Sep 2009 00:14:03 GMT Content-Encoding: gzip X-Content-Type-Options: nosniff X-Frame-Options: SAMEORIGIN Content-Length: 3421 Server: GFE/2.0 ---------------------------------------------------------- And this is our Seaside header... http://localhost:48199/seaside/Test GET /seaside/Test HTTP/1.1 Host: localhost:48199 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3 (.NET CLR 3.5.30729) Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-us,en;q=0.5 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Referer: http://localhost:48199/seaside Cookie: <some cookie data> HTTP/1.x 200 OK Expires: Wed, 11 Jun 1980 08:00:00 -0400 Cache-Control: no-cache,must-revalidate Pragma: no-cache Content-Disposition: attachment;filename=events.ics Content-Type: text/calendar;charset=utf-8 Content-Length: 10944 ---------------------------------------------------------- -- View this message in context: http://www.nabble.com/iCal-to-Drupal-requires-Content-Encoding%3A-gzip-tp25… Sent from the Squeak - Seaside mailing list archive at Nabble.com.

3 2

Seaside 2.9 WARenderloop Replacement
by Karsten 21 Sep '09

21 Sep '09

Hi, i've noticed that WARenderLoop has been removed in Seaside 2.9. The docs on Seaside.st don't mention what class should be used instead, so i'm asking here. When I try to open a new window with a new component the WARenderLoop should have been used in Seaside 2.8. What can I call now to open a new component in a new window? Kind Regards Karsten -- Karsten Kusche - Dipl.Inf. - karsten(a)heeg.de Tel: +49 3496 21 43 29 Georg Heeg eK - Köthen Handelsregister: Amtsgericht Dortmund A 12812

3 3

Deploying a big Squeak/Pharo Seaside application
by Mariano Martinez Peck 21 Sep '09

21 Sep '09

Hi folks: First of all, please if someone answers this mail do it to all as I have cc Gerardo. After ESUG talks I was imagining a way to deploy big seaside applications. Something like this architecture: SqueakNOS SqueakVM Image: The KernelImage that Pavel did. For Pharo it is something like 3MB I think. If you add morphic you can then use the VNC and I think it is 5MB. Then we should load there seaside, the dependencies and all of our code. With this, I can have one real server with a host OS and use VMWare for example to have N number of SqueakNOS images. Each of the SqueakNOS image can have in addition, M number of images running at the same time. Finally we can have a cluster of real pcs and just drag and drop our SqueakNOS VMWare images from one pc to another. So...I wonder: ¿Is this a good idea? ¿Should this have better performance than just having several images running in the same pc? ¿Are there any advantages or disadvantages with this approach? I don't have any big seaside application at all, but I was just thinking hahaha. Best, Mariano

4 4

Configuring exception handler in 3.0?
by Boris Popov 21 Sep '09

21 Sep '09

Is there a better API to change exception handler on an application? I looked, but got lost in the maze of configurations/defaults/filters/whatnot. Here's what I have at the moment, | app | app := WAAdmin register: self asApplicationAt: 'myapp'. (app filters detect: #isExceptionFilter) configuration at: #exceptionHandler put: WADebugErrorHandler. app addLibrary: JQGoogleLibrary; addLibrary: JQUiGoogleLibrary Thanks! -Boris -- +1.604.689.0322 DeepCove Labs Ltd. 4th floor 595 Howe Street Vancouver, Canada V6C 2T5 http://tinyurl.com/r7uw4 boris(a)deepcovelabs.com CONFIDENTIALITY NOTICE This email is intended only for the persons named in the message header. Unless otherwise indicated, it contains information that is private and confidential. If you have received it in error, please notify the sender and delete the entire message including any attachments. Thank you.

3 4

seaside.st is down
by Tudor Girba 20 Sep '09

20 Sep '09

It displays: Proxy Error The proxy server received an invalid response from an upstream server. The proxy server could not handle the request GET /. Reason: Error reading from remote serve Cheers, Doru -- www.tudorgirba.com "There are no old things, there are only old ways of looking at them."

1 0

WAUrl
by Robert Shiplett 20 Sep '09

20 Sep '09

Should I have to subclass WAUrl to avoid WAHtmlDocument in a printOn: ? >>printOn: aStream | document codec | codec := [ self requestContext codec ] on: WARequestContextNotFound do: [ :e | WANullCodec new ]. document := WACurlDocument on: aStream codec: codec. self encodeOn: document usingHtmlEntities: false

4 4

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

seaside September 2009