(Nearly) Real Time River?

So one of my users asked me a question today that got me thinking:

Why do I have to refresh the activity river?

Why indeed?

It seems to me that for this kind of thing, the most obvious thing would be an automatically updating page, so nobody has to refresh. It would make it, in essence, the actually beating heart of an elgg installation, rather than just that place you go back to regularly.

That got me thinking even more. What if you put a "mini-river" in the corner of every page? Or in the sidebar? Or wherever your theme dictated? That way, a user could see things happening on the site no matter where they were.

This got me wondering: why isn't this already done? It seems like such an obvious, obvious step now I think about it.

Unfortunately, I know, if you'll excuse my French, bugger all about AJAX. 

Would there be any interest in this?

  • @ALL

    Vazco has ( as yet unreleased ) AJAX widgets for activity such as River ;-)

  • ...I'm so going to have to smack that guy for releasing stuff that I'm working on. ;) (Entirely good humoured jest, that; kindof glad that ideas I have are ideas people better with elgg are also having.)

    I was working on something similar to the karma plugin he made, too, and he released before me. Darn him! :D

  • @Dago

    Vazco is uno smart Elgg dude ;-)

    I know him ;-O

  • @Dhrup: Ayup, he is indeed. 

  • Set up a second test server to test out ideas for this, but got nowhere so far, sadly (which since I'm putting in maybe an hour of effort per day and not every day, perhaps is not surprising). Now considering using the JSON view that's already part of the riverdashboard somehow instead of my prior approach.

  • Oh, also, on earlier notes on increased load...

    You can significantly reduce overheads by just keeping the HTTP connection -open-. IE, streaming the data to the browser. Downside: not all browsers support this (or, not very well) and you need heartbeat code to ensure you're not streaming to completely idle users.

    If done properly, this could conceivably -reduce- server load because you would not be repeatedly opening a HTTP connection for every time a user reloads the riverdashboard. If you have it as a widget that displays on the sidebar, for example, the only time the connection reopens is when they "naturally" browse to another page. Currently, if someone is watching for activity they have to reload (not necessarily refresh, but still, it's all overhead) the page every so often. That means that if you have the polling configured right, on a large site, you're actually -reducing- overhead, not causing more.

  • Also, I'm running into a freakin' brick wall here. I -cannot- seem to get the container (IE, the river content itself) to display independently of the riverdashboard, which I need in order to get the data to update on polling (for proof of concept, not a final product). Basically I'm hacking at container.php to try to figure out the bare minimum code needed to display the river. Not getting anydamnwhere.

    Other idea is to use the JSON output. Unfortunately, I am not familiar with JSON - I'm familiar with XML - and what I find out on the web isn't tremendously helpful to me so far, since none of it deals with what I'm actually trying to do, per se.

    It's making me want to bite my monitor.

  • I hope it tasted better than mine did

    Anyway just a thought that you have probably considered 

    have you considered looking at the river widget ????? Like I said just a thought

  • @Malaga Jack: It tasted awful, I should clean it more often. -.-

    And.. the river widget.

    *facepalm* You, sir, are a genius. And/or I'm a doofus, but, nonetheless. ;)

  • A prevalent concept that's currently taking the industry by storm is the application of a "publication/subscriber" pattern which is architected on web applications through something called Comet.

    Comet may somewhat seem like a new buzzword, and it is, but the one thing to learn is that it's a meta concept exhausting the above pattern/idioms. The techniques used for web servers relies on something called "long-polling."

    In a gist, it's an infinitley re-connecting socket connection that blocks until the specified block time  interval has passed or a response has been received. When a response is received, Comet "long-polling" will invoke a callback and "subscriber" (i.e. the client javascript et al.) will re-establish a connection to the "publisher" service. If no request has been received, the subscriber will just re-establish a listening connection.

    It is important to note that the publishing service will "queue" responses and/or batch them to the subscriber. This will give the illusion of a "real-time" system, which is what you were trying to accomplish.

    Mahmoud Abdelkader