HTML5 (Javascript) access to Shared Objects

My primary use for Wowza right now is shared objects to allow a presenter to ‘send’ slides to an audience. The audience connects to the shared object with a unique ID and grabs an id from the shared object whenever it changes. Pretty straight forward in Flash.

But I find myself needing to rewrite the system in HTML 5 rather than Flash. Are there any examples of using remote calls from Javascript to set and retrieve shared object contents? I have a dedicated Wowza server so I can add whatever code is necessary to the server as well.

Thanks, in advance.

Without creating a browser plugin, there was not a way to create a bi-directional network socket from Javascript. Until, HTML5 websockets. You can get a Java based HTML5 websocket implementation and integrate this in a wowza custom module, then write your own client/server code to update the shared object.

The Flash RTMP connection is already setup to do this.

Another option would be to setup a Wowza HTTP Provider and then have the clientside webpage poll the HTTPProvider every few seconds to check for updates, or to post an update to the shared object.

I take it your goal is to implement intercommunication between iDevice clients?

You really need Flash RTMP client for applications involving a SharedObject.

Richard

You would need to write your own HTTPProvider to follow Jay’s suggestion, there is nothing built-in

Richard

Not just iDevices, but desktops as well. I need to eliminate my dependency on Flash. When I tell customers my presentation product requires Flash they run away. :slight_smile: I am using Wowza to handle several shared objects, for example to hold the current ‘slide’ id. When the presenter changes slides I post the change to the shared object and the listeners on the other end pick it up and then go download the slide. What I need to do is perform this exchange of information without the use of Flash. Are there any examples of this. I am fluent in php, javascript and server scripting, but not Java itself.

When you say ‘my application’ do you mean a server-side application? Currently I do not have one. I just use the default configuration for shared objects.

Thanks Richard. I’ll look into it. Sounds like an opportunity for Wowza though. The world is moving away from Flash at breakneck speed. We’re all going to need these kinds of tools for the future…

That’s music to my ears Charles. My product is entirely based on the nice little self-contained object called a swf file. I am really struggling to create an HTML 5 equivalent. If nothing else, I had thought the advertising world would help maintain the dependence on Flash as there is no better medium for distributing rich-media ads. But I have many customers, especially enterprise-level, who are resisting investing in a long term relationship with a company that depends on Flash as it’s core technology.

I’ve actually written a full chat stack on top of the HTTP interface wowza exposes. While it does work, a nice web sockets implementation in wowza would rock.

I’m going to look more seriously into integrating a 3rd party web sockets library into my wowza project and see how far I get.

Jake

Technically, you could do this with an HTTPProvider to get around the spotty browser support for web sockets (although it might be a bit messy)

The idea here is that the HTTPProvider will access your application module. The module will expose methods to read from or write to the shared object, and check the version of properties in the shared object, and the HTTPProvider will handle serializing the data (or the changed data) to a javascript friendly format.

The javascript client would then have to poll the httpprovider on an interval to check for changed data.

It would be a bit of a job, but it’s certainly do-able.

No to be controversial here, but really, I think the notion that the world is moving away from flash in any great hurry is a result of drinking too much pundit generated kool-aid (and Adobe’s lousy PR management). While mobile has created reason for having standards based implementations of some applications, there’s still quite a bit that’s either impractical or impossible to do without flash at this point.

Now that some of the initial HTML5 hype has died down, and developers and organizations have had some time to attempt to move to a standards based approach, we’re starting to see a fair number of them coming to the realization that HTML5/Javascript just isn’t there yet, and it will be a good number of years before it is (most notably the gaming and enterprise application spaces… plenty of moves back to flash).

I’m sure that, eventually the standards specs will be completed, and eventually (although a much more distant eventuality), the various browser vendors will bring their products -mostly- up to spec (I say mostly because not a single one of them adheres to older specs 100%), but we’re talking a good number of years off at this point before we get there.

That’s a shame to see how simple things made in Flash became so complex or impossible to do with javascrap. Also it’s crazyness to force developers and companies to rewrite a well proofed web complex application written in Actionscript. Fortunately some very nice projects are emerging, working on how to integrate the whole Flash API int WebAssembly, the main ones being (constantly growing) ruffle

https://github.com/ruffle-rs/ruffle

and CheerpX (no source code for now)

https://community.pcgamingwiki.com/topic/4368-the-preservation-of-classic-flash-based-games-becoming-a-reality-through-leaning-technologies-latest-project-cheerpx/