Hi,
Is there a way to use the same server Seaside is using to plug a ZnWebSocketDelegate into it? The ZnZincServerAdaptor runs by default as the root delegator for its server (at whatever port it was started), but I was wondering if there is a way to reuse the same server Seaside (on top of Zinc) is using, to plug different WS handlers. By now I'm just using another server to run the WS, which is no big deal except to open an extra port in my server. Regards! |
Hi Esteban,
On 13 Mar 2013, at 03:15, Esteban A. Maringolo <[hidden email]> wrote: > Hi, > > Is there a way to use the same server Seaside is using to plug a > ZnWebSocketDelegate into it? > > The ZnZincServerAdaptor runs by default as the root delegator for its server > (at whatever port it was started), but I was wondering if there is a way to > reuse the same server Seaside (on top of Zinc) is using, to plug different > WS handlers. > > By now I'm just using another server to run the WS, which is no big deal > except to open an extra port in my server. > > Regards! I have several images that run multiple servers concurrently, especially separating the web socket stuff in a second server sounds like a good idea to me. By fiddling with different mappings in the default handler you can actually set up quite complex systems (like routes in other systems). But of course, there can only be one / handler. Regarding the Zinc Seaside Adaptor, some recent changes make it possible to run Seaside under /seaside instead of under /. ZnSeasideServerAdaptorDelegate>>installInServer: znServer underPrefix: prefix "Install a ZnSeasideServerAdaptorDelegate in znServer under prefix, provided znServer contains a ZnDefaultServerDelegate instance as primary delegate. Note that the incoming request is destructively modified." | seasideDelegate | seasideDelegate := self forServer: znServer. znServer delegate map: 'seaside' to: [ :request | request uri segments: request uri segments allButFirst. seasideDelegate handleRequest: request ]. ^ seasideDelegate Now execute the following line WAAdmin defaultDispatcher serverPath: prefix. And Seaside now works mostly as usual, including links and static files. There seem to be some links that don't work, but I guess that are actually bugs. Mind you, this is all a bit bleeding edge ;-) This might be interesting as well: http://forum.world.st/Running-ZnZincServerAdaptor-outside-WAServerManager-tt4662331.html Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill |
In reply to this post by Esteban A. Maringolo
Am 13.03.2013 um 03:15 schrieb Esteban A. Maringolo <[hidden email]>: > Hi, > > Is there a way to use the same server Seaside is using to plug a > ZnWebSocketDelegate into it? > > The ZnZincServerAdaptor runs by default as the root delegator for its server > (at whatever port it was started), but I was wondering if there is a way to > reuse the same server Seaside (on top of Zinc) is using, to plug different > WS handlers. > > By now I'm just using another server to run the WS, which is no big deal > except to open an extra port in my server. I had the same problem. I wanted to deliver an image without frontend server so the extra ports can be somewhat awkward. I didn't adopt the newest changes from Sven, yet. I do it this way startServer | staticFileDelegate seasideAdaptor | seasideAdaptor := ZnZincServerAdaptor port: self port. WAServerManager default adaptors do: [:each| WAServerManager default unregister: each ]. staticFileDelegate := NTedStaticFileServerDelegate new directory: ( FileDirectory default containingDirectory directoryNamed: 'web'). (ZnServer startDefaultOn: self port) debugMode: true; delegate: ( NTedContextDispatcherDelegate new map: 'ws' to: (ZnWebSocketDelegate map: 'ws' to: NTedWebSocketHandler new); map: 'css' to: staticFileDelegate; map: 'js' to: staticFileDelegate; map: 'img' to: staticFileDelegate; map: 'font' to: staticFileDelegate; map: 'csv' to: NTedCSVHandler new; map: 'admin' to: ( NTedContextDispatcherDelegate new map: 'css' to: staticFileDelegate; map: 'js' to: staticFileDelegate; map: 'img' to: staticFileDelegate; map: 'font' to: staticFileDelegate; defaultHandler: (ZnSeasideServerAdaptorDelegate with: seasideAdaptor) ); defaultHandler: staticFileDelegate ). This way I start a one click image server that contains its static resource within the one click distribution directory and serves WebSockets, a little CSV http handler and seaside for the admin interface. All on the same port and ready when the image is opened. NTedStaticFileServerDelegate is basically a ZnStaticFileServerDelegate that adds some cache headers for resources. NTedContextDispatcherDelegate maps context paths to handlers. It uses a path consumer so that you can use more levels of configuration like in the above example. That means every level takes away the first part of the url. Hope that helps, Norbert |
Thank you guys.
I think I'll go with Norbert's proposal, but after I stabilize all this mess I have :) Norbert, is the NTedContextDispatcherDelegate public and available somewhere? Can you explain more what it does, because AFAIK ZnStaticFileServerDelegate already does a proper use of the etag. Regards! |
Free forum by Nabble | Edit this page |