Opened 12 years ago

Closed 11 years ago

Last modified 11 years ago

#4198 closed task (fixed)

Port Dojo Flash and Flash Storage Provider from 0.4.1 to 0.9

Reported by: bradneuberg Owned by: bradneuberg
Priority: high Milestone: 1.1
Component: Storage/Flash Version: 0.9
Keywords: Cc: alex
Blocked By: Blocking:

Description

The Dojo Flash Storage Provider is not currently working on 0.9; I tested it out against the current version of SVN this week -- I thought that someone else might have patched it to work for 0.9, but this is not so. Like I said I don't have the bandwidth to focus on this right now -- I must focus on paying work and other priorities right now. I can't apply any Flash related patches until the underlying system works.

Here are the tasks that remain to be done if someone wants to tackle this issue; this is perhaps about 2 1/2 weeks of work, especially if there are unknown issues that must also be solved, which is common to working with Flash/JavaScript? interaction -- if someone depends on this code commercially, I am available to do it under a consulting contract so as to focus on it:

1) In dojox/storage/_common.js, we pull in our different storage providers (Gears, Flash, WhatWG). When I do a build for Dojo Offline, I _don't_ want to pull in the Flash or WhatWG provider since they bloat the size of the Dojo Offline offline.js profile file; however, I couldn't get the Dojo build system to dynamically not include FlashStorageProvider?.js and WhatWGStorageProvider.js -- you will see that I had to comment out the following lines in _common.js:

FIXME: Find way to set isGears from offline.profile.js file; it didn't work for me dojo.requireIf(!dojo.isGears, "dojox.storage.FlashStorageProvider?"); dojo.requireIf(!dojo.isGears, "dojox.storage.WhatWGStorageProvider");

I hardcoded just pulling in the GearsStorageProvider? if you say dojo.require("dojox.storage"); from your JavaScript? file. This means that JavaScript? code that depends on the old Flash storage provider will not work, since a call to dojo.require("dojox.storage") will only pull in the GearsStorageProvider?.

This task therefore involves figuring out how to get the Dojo Offline profile build to only include the GearsStorageProvider?, while also somehow keeping the requireIfs() in there if Gears is not part of the build so that older code that depends on the Flash/WhatWG stuff will work.

2) Dojox Flash itself needs to finish being ported -- it is partially ported (special thanks to Alex for helping with that). This will involve getting mtasc, which you can download from http://www.mtasc.org/ . This is just a simple command line tool that you place within your path.

For Dojox Flash, the unit test file is not in the 0.9 file layout yet -- it is in the 0.4.1 layout and can be found in tests/flash/. There are two unit test files in here; they do a variety of tests across the Flash/JavaScript? boundry. All the tests should pass, except one will fail -- Flash asychronously calling JavaScript? I think -- this never passed originally, because I didn't need it for Dojo Storage. These files should move into dojox/flash/tests and be adapted for the 0.9 syntax.

You must also port the Dojo Flash build system, which is currently only in 0.4.1 and which consists of the following tasks: 'buildFlash', 'buildDojoFlash', and 'buildStorageFlash'. These need to be ported to the new 0.9 JavaScript? based build system (which should be relatively straightforward -- if you look at those tasks they basically run mtasc in different ways -- just do this from JavaScript?).

Getting Dojox Flash to work is a necessary precondition to the next step.

3) WhatWGStorageProvider already works in 0.9 -- I got that working a few months ago. The actual provider works, just not the issues with _common.js I identified above. Inside of the FlashStorageProvider? (and possibly inside of Dojox Flash), you might have to update how it finds the resources it needs, since paths have changed from the move to 0.4 to 0.9 (for example, the path to the flash6_gateway.fla might be different, since it is inside dojox/flash/flash6/ now instead of in the root of the Dojo tree, like in 0.4.1).

4) QA across supported platforms and fix any bugs you might find from the 0.9 port or platform/Flash drift:

Mac - Safari/Flash? 6 Mac - Safari/Flash? 8+ Mac - Firefox 1.4 (not Firefox 2 since that is WhatWG provider)/Flash 8 Mac - Firefox 2 - Should go to WhatWG provider Windows - IE 6/Flash 8 Windows - IE 7/Flash 8 Windows - Firefox 1.4/Flash 8 Linux (testing on Ubuntu usually) - Firefox 1.4/Flash 8 Linux - Firefox 2 - Should go to WhatWG provider

Change History (16)

comment:1 Changed 12 years ago by Adam Peller

Cc: alex added

comment:2 Changed 12 years ago by Adam Peller

(In [10275]) Merge Julian's patches for flush (performance; in 0.4 branch) and get/putMultiple (also for performance, parallel to support now in Gears) Rebuilt Storage swf for Flash 8, built Storage swf for Flash 6. Fixes #3213, #3266

Ported over some 0.9 references, but still unable to run test. Fails at dojox.flash.comm.put. Refs #4198 Having the unit tests running would probably help.

comment:3 Changed 12 years ago by Adam Peller

Also missing, apparently, is the Java necessary for Safari and Opera to work (see buildFileStorageProvider in 0.4 build.xml)

comment:4 Changed 12 years ago by bradneuberg

Hi Adam, thanks for taking a stab at this. The Safari/Opera? Java work was just a prototype and never worked -- there wasn't enough demand for it, and it just added too much complexity. You can safely leave it out.

For 0.4.2, the unit tests all ran correctly except for when Flash tried to call back to JavaScript? asychronously (i.e. it wasn't a return result but Flash calling to JavaScript? itself). I never needed that for my own work, and my own deadline was approaching to get Dojo Storage out the door. I've never had any demand from folks to get that working or any personal use for it. If you can get all the unit tests to work except that one on 0.9 than things should be fine.

comment:5 Changed 12 years ago by Adam Peller

Brad, currently there is an error referencing dojox.flash.comm.put, etc. There is a dojox.flash.comm object, but only methods beginning with "_", like _fs methods... but nothing like get/put, which I imagine is where the bridge magic is where you link in the instructions. Could you shed some light on this? I believe I followed the build steps, yet there seems to be some problem at the bridge. Any suggestions? I'm wondering if anything special must be done to link in DojoExternalInterface?.as besides include it in the mtasc -cp arg, or the .fla file, the latter doesn't seem to be referenced anywhere in the old ant script. (see dojox/storage/build.sh for my simplified attempt at a build script) I'm currently trying to get flash6 working. Haven't tried 8

Also, I guess I'm a bit confused about whether dojox.flash needs any further work, or whether unit tests can be running there independently of dojox.storage.

comment:6 Changed 12 years ago by bradneuberg

Hi Adam, unfortunately some of my knowledge around this stuff has gotten a bit hazy since its really been about a year since I've looked in depth into the Dojo Flash stuff -- I got it working and then just used it as an end-user. Dojo Flash is separate from Dojo Storage and is independent; you wouldn't find any Dojo Storage methods in there, such as put or get methods. At the top of the Dojo Flash main files (flash.js) is a giant documentation block that goes in depth into the techniques used internally; have you gotten to review those? Is there missing info?

What you are probably seeing is this; when you instantiate Dojo Flash, which Dojo Storage does, you point it at a Flash 6 and a Flash 8 version of what you are working with (from the 0.4.2 source):

var swfloc6 = dojo.uri.moduleUri("dojo", "../Storage_version6.swf").toString(); var swfloc8 = dojo.uri.moduleUri("dojo", "../Storage_version8.swf").toString(); dojo.flash.setSwf({flash6: swfloc6, flash8: swfloc8, visible: false});

Dojo Flash then 'copies' these methods and exposes them on dojox.flash.comm. In the case of Dojo Storage, this would be dojox.flash.comm.put, dojox.flash.comm.get, etc. If you get an error with those, then it is probably the underlying Dojo Flash system that is breaking, or the build system.

Because creating separate SWF files for Flash 6 and Flash 8 are tedious, the buildFlash method basically would allow you to point it at an ActionScript? file, such as Storage.as, and would automagically produce a Flash 6 SWF and a Flash 8 SWF suitable for pointing the dojo.flash.setSwf() method at. The buildDojoFlash basically calls buildFlash in order to build any Flash-files that Dojo uses, which is just the Dojo Storage Storage.as file at this time.

For Flash 8 calling, things are easy -- we just use ExternalInterface? (though note that there are a bunch of crazy internal performance hacks I had to do to make this work within the lifetime of the universe, since things were really slow). For Flash 6 calling, I backported ExternalInterface? to Flash 6.

Hopefully the docs at the top of the flash.js file can help. I also have an old presentation from about 2 years ago where I went in pretty deep into the internal mechanisms of all this: http://codinginparadise.org/weblog/2006/05/new-slides-from-ajax-experience-talk.html

Feel free to keep asking tech questions around this stuff, on this bug entry; like I said, Dojo Flash is a big hack, but it is the only hack that (unfortunately) can provide the performance and compatibility necessary for Dojo Storage. This is one of the reasons I was a bit loath to venture back into it recently, and also why Google Gears is a bit of fresh air for me in terms of client-side storage so I can just use that ;)

comment:7 Changed 12 years ago by Adam Peller

Brad, not sure this helps much. I'm looking for a shorter comment with more cause/effect. The editorializing doesn't really help. e.g. how does put get into dojox.flash.comm and where I would debug. I know you dread going back into this code you wrote, but I've put some investment in this and should you find the time, I'd bet you could find this problem far more quickly than I could learn it from scratch. In the meantime, I think I'm at a dead end.

comment:8 Changed 12 years ago by bradneuberg

Milestone: 1.1
Owner: bradneuberg deleted

I'm going to mark this as WONTFIX if someone doesn't step forward and volunteer to do it; as I've said repeatedly, I don't have the bandwidth to support this area of the system anymore.

comment:9 Changed 12 years ago by Adam Peller

ok, until such time as this is opened then, we need to de-support the code (remove from the release?)

comment:10 in reply to:  9 Changed 12 years ago by jfcunat

Replying to peller:

ok, until such time as this is opened then, we need to de-support the code (remove from the release?)

We still need this feature in our projects, does anybody have the time to port it ?

comment:11 Changed 12 years ago by bradneuberg

Hi jfcunat, I am available for paid consulting to do this. I estimate two weeks of work with the tasks given in the initial bug report. I unfortunately can't afford to take two weeks off of paid consulting work to focus on this for free, but can if someone helps fund it. I am the initial creator of Dojo Flash.

comment:12 Changed 11 years ago by Adam Peller

Milestone: 1.1

nobody has this on their plate atm.

comment:13 Changed 11 years ago by dylan

Milestone: 1.2
Owner: set to bradneuberg

comment:14 Changed 11 years ago by bradneuberg

This is the major bug I am working on right now. I have finished refactoring Dojo Flash to now work with most recent browsers and Flash versions. I now need to hook it into Dojo Storage and refactor the FlashStorageProvider?. I can't make 1.1 but will have by 1.2.

comment:15 Changed 11 years ago by Adam Peller

Milestone: 1.21.1
Resolution: fixed
Status: newclosed

Fixed in [13009]. Thanks, Brad!

comment:16 Changed 11 years ago by Adam Peller

(In [13428]) Fix jsdoc summary. Also, bump rev and remove 'broken' status from README. Refs #4198

Note: See TracTickets for help on using tickets.