Forum OpenACS Development: Re: Toughts on an Event Engine

I created a GitHub repo and committed my package.

The url is this: https://github.com/Elettrotecnica/OpenAcs-Event-Handler

My event handler is entirely based on plain Aolserver API, with the only exception of the ad_proc syntax.

In the www folder of the package you can find a simple example of the package at work. One is the event creator, the other is the event handler. The first keeps firing events, while the second reacts to one or more of them executing a piece of code.

On the server side, this mechanism is totally agnostic regarding websockets or other advanced web techniques, just a lean and mean HTTP response.

Any comment will be much apreciated!

Thanks Brian!

I updated the code to allow the specification of a different script for each event caught. This way the mechanism should be more flexible.

The examples in www exploit the new feature.

We have a comet implementation in OpenACS+Aolserver since a few years which allows to keep a push channel to potential multiple clients open. See:

https://openacs.org/forums/message-view?message_id=423438
http://www.openacs.org/xowiki/tag/COMET

all the best
-gustaf neumann

The mentioned patches are included in aolserver and NaviServer since about 4 or 5 years. If you have e.g. aolserver 4.5.1, you are fine. The Chat packages is not needed for testing the chat functionality. It is easier, if you use just xowiki. Create a page of type ::xowiki::Object and use the following as content:

proc content {} {
  ::xowiki::Chat login -chat_id 22
}

When you render this page, you see the chat dialog. One can have multiple chats concurrently running. Every chat is identified by a chat_id. In the example above, the chat-id "22" is an arbitrary number. You might choose to use e.g. the package-id of xowiki as chat-id, but then you would permit a single chat per xowiki instance.

While testing, i saw that current browsers require chunked encoding for streaming HTML output. If the example above does not work for you in your installation, please upgrade xotcl-core to get the version with chunked encoding support.

all the best

-gustaf neumann

The change introducing chunked-encoding is just in the bgdelivery procs. Have you got this patch?
http://cvs.openacs.org/changelog/OpenACS?cs=MAIN%3Agustafn%3A20130129073959

I have tested this with FF 19 and Google Chrome, but i don't have my full development environment, since i am currently on vacation in the colorado rocky mountains... But i am pretty sure, with the patch it will work.

all the best
-gustaf neumann

i am not sure, how we manage the debian releases of OpenACS in general, but i think, the patch is quite local, so it should not cause unexpected side effects.

As you can see from the postings from 2006, i have tried various alternatives and the technique with the script tags worked out best. Several comet implementations seem to implement this now as well. The biggest limitation are probably that Tcl's event management via select() is practically limited to 1000 file handles, and it requires plain http communication (one would need a reverse proxy or similar to handle ssl/tls). These limits can be overcome, but these are not high on my priority list.

Generalizing is pretty straight forward, since the script tags simply fill up some json objects, which are handled by a javascript handler at the end.

let me know, when you have something.

all the best
-gustaf neumann

Looks like there is not a way to make pure streaming work on Explorer. Opera too has issues, as it fires the onreadystateevent only once and would require continuous polling of the responseText...

Windows versions of Firefox and Chrome work fine. Safari on Windows is ok too, but as Konqueror, keeps showing the loading spinner even on pure streaming... well...

Anyway... looks like the best practice for comet streaming had already been achieved. Scripted streaming for Explorer, responseText polling for Opera (which I wouldn't mess with) and pure streaming for the rest.

I modified the regexp so it allows pure streaming for every browser except Opera and Explorer.

I can provide the modified files.

Yes, scripted streaming is the most portable technique, and it's not unelegant, but suffers from the "neverending spinner" problem. I like more the pure streaming solution because it is very "How it should be if world was a perfect place"...

As you already found out in 2006, seems like some sort of compromise is always required when you deal with server push on the web. In this years nothing really changed, and this will stay true until everybody (Microsoft...) will adopt newer techniques like websockets and similar, or implement their event handlers the way they should be.

Here is a dropbox link to the files.

http://dl.dropbox.com/u/7119685/gustaf.zip

Thanks to you for your support, I'm glad to give my little contribution.

Commit seems fine to me, the comment is very explicit and explains clearly how to choose the right method.

That said, I have some more modifications which I would like to expose and discuss with you:

in these days I managed to implement notifications on my portal using your Comet chat. It works like this: the master template included in every page calls the login on the chat, then waits for any message to occour (messages are sent by other pages).

The normal workflow of my users (the portal is an ERP) causes many and many calls of the login method, as there is little to no use of ajax and the master template is always called. Every time the chat logs in it opens a new channel.

After some hours this took to the reach of the 1000 file handles you were talking about and to a reboot of the server.

I dug some more into the code: when a message is sent to the subscribers, it is checked wether the channel is still alive, and if it's not it is closed. This works good in a proper chat, where messages are sent quite often. In my situation tough, this happens only seldom, as the notified events are not frequent, so dead channels are never cleaned.

I created a new method in the Subscriber class of bgdelivery, which takes care of cleaning dead channels every time someone subscribes. Similar methods exist for other objects in the bgdelivery, and seems like this solved the issue.

Also, I was not super happy about my previous change in the bgdeliveries-procs: after setting the content type to octet stream, the encoding of the characters had to be solved on the client side, causing extra effort to the end user. I found out I could just use the "encoding" command to translate the message server side, avoiding to use "escape" on the client.

I changed the chat page in xowiki too, only to allow the sending of messages containing html. If I don't allow it, it is impossible to send even the char "<", and it should be safe, because we already quote all the html in the message on the server.

I updated the zip file I linked to include the modifications I am talking about. The bgdelivery-procs file had been checked against your last cvs commit.

Let me know if it could be ok for you.

Best regards

Antonio