seaside-dev January 2013

seaside-dev@lists.squeakfoundation.org

10 participants
6 discussions

Fwd: [Seaside Commits] Seaside 3.0: ConfigurationOfSeaside30-dkh.376.mcz
by Julian Fitzell 29 Jan '13

29 Jan '13

Anybody know what the deal is with these 7 commit messages that keep getting sent out again and again every few weeks? ---------- Forwarded message ---------- From: <squeak-dev-noreply(a)lists.squeakfoundation.org> Date: Tue, Jan 29, 2013 at 11:45 AM Subject: [Seaside Commits] Seaside 3.0: ConfigurationOfSeaside30-dkh.376.mcz To: commits(a)lists.seaside.st Dale Henrichs uploaded a new version of ConfigurationOfSeaside30 to project Seaside 3.0: http://www.squeaksource.com/Seaside30/ConfigurationOfSeaside30-dkh.376.mcz ==================== Summary ==================== Name: ConfigurationOfSeaside30-dkh.376 Author: dkh Time: 21 September 2012, 10:13:05 am UUID: bebc2dee-45d1-4b9c-bccf-181df5855714 Ancestors: ConfigurationOfSeaside30-dkh.375 release 3.0.7.1 for GemStone 3.1.x _______________________________________________ commits mailing list To unsubscribe, email commits-leave(a)lists.seaside.st http://lists.seaside.st/listinfo/commits

2 1

Broken build because of use of #includesSubstring:
by Lukas Renggli 16 Jan '13

16 Jan '13

Hi Ken, Looks like your change of #includesSubString: to #includesSubstring: broke Seaside 3.1: http://jenkins.lukas-renggli.ch/job/Seaside%203.1/lastCompletedBuild/testRe… The same problem appeared in the past on other packages (Pier, Magritte). Can you revert the change? Cheers, Lukas -- Lukas Renggli www.lukas-renggli.ch

5 10

WAComboResponse + Zinc
by Ken Treis 13 Jan '13

13 Jan '13

I thought I'd try to make the Zinc server adaptor use WAComboResponse (like the Comanche adaptor does), but I'm running into some issues. 1. I need a handle on the underlying stream, but this is unknown to the ZnRequest once it's been read. ZnServer knows it, and the entity (if any) knows it if it's been read in a streaming fashion, but otherwise the stream isn't available to the Seaside server adaptor. 2. The Zinc server expects to write a response every time -- it doesn't have the #isCommitted plumbing that Comanche does for checking whether a response has already been committed. I was first tempted to modify Zinc itself (in blatant violation of the open/closed principle), but perhaps it'd be better to make a new subclass of ZnServer that'd handle these issues natively. The only downside: you'd lose the ability to plug your own ZnServer into your Seaside adaptor. Maybe that's OK, if everybody's basically using the "managing multi-threaded" approach anyway. Do we really need the flexibility of a pluggable threading approach? Any thoughts/direction would be greatly appreciated. Thanks, Ken

4 10

Seaside-Rest and routing engine
by Norbert Hartl 08 Jan '13

08 Jan '13

Is there any reason the Seaside-REST-Core-Route needs to be in the Seaside-REST-Core package?. As far as I can see the routing is not dependent on seaside. It would work as well if it uses GRError base class instead of WAError and GRObject instead of WAObject, right? I see the routing is useful even outside the scope of seaside. The Seaside-REST-Core-Handler package uses the Seaside-REST-Core-Route package. So, is there any reason not to make the routing independent? thanks, Norbert

2 2

Can WAServerAdaptor be split up?
by Norbert Hartl 07 Jan '13

07 Jan '13

I'm experimenting at the moment with setups to serve static files from a one click image without using file libraries. I'm trying to serve static files from within a one click distribution directory. Therefor I create a zinc server myself and I want to plug in seaside as a handler. Here is a snippet start "file delegate serves from a neighbor directory 'web'" staticFileDelegate := ZnStaticFileServerDelegate new directory: ( FileDirectory default containingDirectory directoryNamed: 'web'). server := (ZnServer on: self port) delegate: ( "the next class just maps the first path element of a uri to a handler" NTedContextDispatcherDelegate new map: 'css' to: staticFileDelegate; map: 'js' to: staticFileDelegate; defaultHandler: (ZnSeasideServerAdaptorDelegate with: ZnZincServerAdaptor new) ). server start Whenever I start my server there is another adaptor created on port 8080. This is due to ZnZincServerAdaptor is an instance of WAServerAdaptor and always starts a server instance with a default being port 8080. In my opinion WAServerAdaptor has too many responsibilities. It does server management as well as request conversion. From a seaside point of view (being monolithic) this seems not to be a problem. But if seaside is _just_a_ handler it strikes back. I would like to divide the server management code from the request conversion. The request conversion/adaptor class could also be used in zinc directly. Meaning the only difference would be if seaside is the only zinc delegate or is a composited delegate. If it is important to keep a WAServerAdaptor as it is there could be one class having self as delegate resembling the current behavior. Any opinions? I would do the split up but I wanted to ask first if there is anything speaking against it. Norbert

3 2

Re: Can WAServerAdaptor be split up?
by Sven Van Caekenberghe 07 Jan '13

07 Jan '13

Hi, In the regular Seaside mailing list, I wrote a message 'Running ZnZincServerAdaptor outside WAServerManager', describing my first attempt at solving Norbert's problem, within the existing architecture. Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

seaside-dev January 2013