ZnWebSocket and Seaside ZnZincServerAdaptor

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

ZnWebSocket and Seaside ZnZincServerAdaptor

Esteban A. Maringolo
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!

Reply | Threaded
Open this post in threaded view
|

Re: ZnWebSocket and Seaside ZnZincServerAdaptor

Sven Van Caekenberghe-2
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


Reply | Threaded
Open this post in threaded view
|

Re: ZnWebSocket and Seaside ZnZincServerAdaptor

NorbertHartl
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



Reply | Threaded
Open this post in threaded view
|

Re: ZnWebSocket and Seaside ZnZincServerAdaptor

Esteban A. Maringolo
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!