From mark at novemberborn.net Sun Mar 23 16:35:39 2008 From: mark at novemberborn.net (Mark Wubben) Date: Sun, 23 Mar 2008 17:35:39 +0100 Subject: [sIFR3-dev] r386 and Flash 9 Message-ID: <755F096A-7348-4FD3-9295-BB4E09260199@novemberborn.net> Hey all, it's been a while, but I've just put up r386 which contains the results of my refactoring effort of the JavaScript code. Visible to the outside are some API changes: > [REMOVED] The `sIFR.preserveSingleWhitespace`, `sIFR.fixWrap`, > `sIFR.forceClear` and `sIFR.fromLocal` options have been removed. I > don't think these were used often anyway. > > [REMOVED] Removed support for loading Flash movies for specific > Flash player versions. > > [REMOVED] Removed `sIFR.prefetch()` method. Pass the movies to > `sIFR.activate()` instead. > > [CHANGED] `sIFR.callbacks` has been renamed to `sIFR.replacements`. > `sIFR.getCallbackByFlashElement()` has been renamed to > `sIFR.getReplacementByFlashElement()`. > > [CHANGED] Changed User Agent detection a bit. Most significant > changes is that `sIFR.ua.geckoBuildDate` has been replaced by > `sIFR.ua.geckoVersion`, since the build date does not actually > correspond to the rendering engine version. All `sIFR.ua.*Version` > properties have changed, they're now special strings so JavaScript's > string comparison can be used to test for browser versions > (supporting versions like `1.5.0.12`). If you want to write your own > version checks, compared the `sIFr.ua.*Version` properties to > `sIFR.ua.parseVersion("1.5.0.12")`. The `parseVersion()` method > creates the same string as the `*Version` properties so it can be > compared. Browser support has also changed a bit, with the addition of Opera 9.50 and the disappearance of Firefox < 1.5.0.12 support. It's the internal changes that are the coolest though. Locally (that is, on my machine, haven't put this in the release yet) the code now consists of several files: > sIFR > UserAgentDetection > Util > DomUtil > MovieCreator > FlashInteractor > ClassNames > Errors > hacks/FragmentIdentifier > hacks/PageLoad > hacks/Prefetch Using a build script these files are cleverly merged into one sifr.js file. The huge upside of this process is that it's now possible to rewrite the sIFR internals using 3rd party libraries. For example I've already played around with using jQuery functions and using SWFObject for embedding the Flash movie. One downside is that this process is all string based, so rather vulnerable to changes in the sIFR code. Not sure what to do about that, yet. I also need to find out how portable the build script is, so anyone who wants to make custom builds of sIFR, please get in touch! I've also rewritten the communication between Flash and JavaScript, which now uses ExternalInterface. Combined, the changes are pretty huge, and r386 needs testing. It'd be great if you folks could give it a shot on your own sites. Please do note that the API has changed in some places, and that this is not reflected yet in the wiki. Finally, provided I can get my hands on a copy of Flash CS3, I'm thinking about rewriting the Flash part to Flash 9 and ActionScript 3. This should make sIFR more compatible with the future (hah!), and I'm hoping to use the command-line tools to generate sIFR movies without using Flash. Would love to hear your thoughts on this. Regards, -- Mark From davebytes at comcast.net Mon Mar 24 13:01:36 2008 From: davebytes at comcast.net (David Chait) Date: Mon, 24 Mar 2008 09:01:36 -0400 Subject: [sIFR3-dev] sifr3-dev Digest, Vol 24, Issue 1 In-Reply-To: References: Message-ID: <47E7A630.2020900@comcast.net> My concerns are: - moving target to work with. ;) (every time I think about integrating a new version, I get an email with a new release with big changes! ;) ) - getting to a final, stable release that people can/will use for YEARS. get '3' out the door, and work on '3.1', or '4'. - shifting Flash reqs once again (early in sifr3 dev was the shift to 7+8, right?), and losing a ton of intermediary installed base for which sifr3 would give improvements over sifr2 for designers... I'm a big proponent of tools for generating the sifr movies that don't require CSn... but I'd like to see sifr3 continue to support some earlier flash variants though, unless there's strong data to drop backwards support... ;) -d > Finally, provided I can get my hands on a copy of Flash CS3, I'm > thinking about rewriting the Flash part to Flash 9 and ActionScript 3. > This should make sIFR more compatible with the future (hah!), and I'm > hoping to use the command-line tools to generate sIFR movies without > using Flash. Would love to hear your thoughts on this. > From mark at novemberborn.net Mon Mar 24 14:15:01 2008 From: mark at novemberborn.net (Mark Wubben) Date: Mon, 24 Mar 2008 15:15:01 +0100 Subject: [sIFR3-dev] sifr3-dev Digest, Vol 24, Issue 1 In-Reply-To: <47E7A630.2020900@comcast.net> References: <47E7A630.2020900@comcast.net> Message-ID: On Mar 24, 2008, at 14:01, David Chait wrote: > My concerns are: > - moving target to work with. ;) (every time I think about > integrating > a new version, I get an email with a new release with big > changes! ;) ) Yea I know. This was the last JavaScript refactoring I had planned though, so other than fixing bugs it shouldn't change (too much?). > - getting to a final, stable release that people can/will use for > YEARS. get '3' out the door, and work on '3.1', or '4'. Oh yes. Get v3 out of the door, and then preferably find someone else for subsequent version. > - shifting Flash reqs once again (early in sifr3 dev was the shift to > 7+8, right?), and losing a ton of intermediary installed base for > which > sifr3 would give improvements over sifr2 for designers... Fair point. However, you need to take the long development history of v3 into account. I mean, I started work on it like 2.5 years ago, when Flash 8 was still brand new. These days, even Flash 9 isn't very new anymore. Adobe's stats from last December [1] show 93 - 95% market penetration, and this will only be higher by the time v3 is finally ready ;-) I'm also thinking ahead, ActionScript 3 is the way to go for Flash programming, and it may be a smart investment for future development to have an AS3 version. Personally I'm not worried about development time regarding a port to AS3, I can do that in less than a day. A bigger problem is the install base of Flash IDEs, which brings us to: > I'm a big proponent of tools for generating the sifr movies that don't > require CSn... but I'd like to see sifr3 continue to support some > earlier flash variants though, unless there's strong data to drop > backwards support... ;) I think that if we have the tools it shouldn't matter much, especially going forward. Do you think my data [1] is strong enough? Thanks for your comments, as always, [1]: http://www.adobe.com/products/player_census/flashplayer/version_penetration.html -- Mark From davebytes at comcast.net Tue Mar 25 15:10:54 2008 From: davebytes at comcast.net (David Chait) Date: Tue, 25 Mar 2008 11:10:54 -0400 Subject: [sIFR3-dev] sifr3-dev Digest, Vol 24, Issue 1 In-Reply-To: References: <47E7A630.2020900@comcast.net> Message-ID: <47E915FE.2070109@comcast.net> Understood. But note that another version shift, invalidation of existing sifr3 resources/fonts can be a headache for some designers (who might then not upgrade at all). Granted, there's been changes/fixes along the way that necessitated rebuilding of files anyway. ;) What does going to F9+AS3 give us? Are there new visual features to further enhance the sifr-offering? Will that make cmdline, non-FCS3 tools, a reality? Should those be sifr3, or let someone else tackle them for a 'sifr4'? Or, that is to say, where IS sifr3 at right now in terms of features and bugs? Could it be frozen, released, and ONLY bugfixes, and then go ahead and do your shift to F9+AS3 as 'sifr4'? Does that win us anything, or are we better off shifting now to F9? How much time will it take to migrate over? (real world time...) In terms of Adobe's numbers... they are interesting, but only tell a part of the story. I guess the people who would use F9 for site development already won't care if sifr3 jumps to F9 -- but for all the people using 7 or 8, they're at a dead end the moment you switch. Thus I'm wondering if better, even just for YOUR sanity, to declare sifr3 final and branch to sifr4 to do the new/real work you want to do. Is the current code stable, functional, tested enough that it can be deployed widely? Those are the sorts of Qs that come to mind. I already appreciate your efforts driving this technology forward, over a long period. The reality is that without setting release goals, without setting versions, milestones, bug releases, sifr3 just keeps hanging in 'beta', and you probably have a hundred different release versions floating around on different websites (which is bad, esp if there are security issues in any of them!). To close... While we're all 'consumers', it's really your baby at this point. If you want to do F9, go for it -- though I'd still do it as 3.1 or 4.0 even just to be VERY clear to less-programmer types the large shift that is occurring. And then target real releases, go for stability, go for widespread use. Institute a sifr-announce list (if there isn't one), and make EVERYONE downloading sifr3 sign up for it so they get notices of bugfixes and security releases (my guess is not enough folks sub to this list, though I could be wrong...). And, if there's HUGE benefit to F9 as a shift, in terms of immediate (<1mo) next release along with tools (F9 change could 'strand' fonts again... another reason to call it 4.0...), in terms of new visuals (I love adding visual effects for people who aren't programmers OR designers...), I'm game. Let's just choose the right path, timing, naming, to get it adopted well in the industry. -d Mark Wubben wrote: > On Mar 24, 2008, at 14:01, David Chait wrote: >> My concerns are: >> - moving target to work with. ;) (every time I think about integrating >> a new version, I get an email with a new release with big changes! ;) ) > > Yea I know. This was the last JavaScript refactoring I had planned > though, so other than fixing bugs it shouldn't change (too much?). > >> - getting to a final, stable release that people can/will use for >> YEARS. get '3' out the door, and work on '3.1', or '4'. > > Oh yes. Get v3 out of the door, and then preferably find someone else > for subsequent version. > >> - shifting Flash reqs once again (early in sifr3 dev was the shift to >> 7+8, right?), and losing a ton of intermediary installed base for which >> sifr3 would give improvements over sifr2 for designers... > > Fair point. However, you need to take the long development history of > v3 into account. I mean, I started work on it like 2.5 years ago, when > Flash 8 was still brand new. These days, even Flash 9 isn't very new > anymore. Adobe's stats from last December [1] show 93 - 95% market > penetration, and this will only be higher by the time v3 is finally > ready ;-) I'm also thinking ahead, ActionScript 3 is the way to go for > Flash programming, and it may be a smart investment for future > development to have an AS3 version. > > Personally I'm not worried about development time regarding a port to > AS3, I can do that in less than a day. A bigger problem is the install > base of Flash IDEs, which brings us to: > >> I'm a big proponent of tools for generating the sifr movies that don't >> require CSn... but I'd like to see sifr3 continue to support some >> earlier flash variants though, unless there's strong data to drop >> backwards support... ;) > > I think that if we have the tools it shouldn't matter much, especially > going forward. Do you think my data [1] is strong enough? > > Thanks for your comments, as always, > > [1]: > http://www.adobe.com/products/player_census/flashplayer/version_penetration.html > > > -- > Mark > > From mark at novemberborn.net Wed Mar 26 10:10:44 2008 From: mark at novemberborn.net (Mark Wubben) Date: Wed, 26 Mar 2008 11:10:44 +0100 Subject: [sIFR3-dev] sifr3-dev Digest, Vol 24, Issue 1 In-Reply-To: <47E915FE.2070109@comcast.net> References: <47E7A630.2020900@comcast.net> <47E915FE.2070109@comcast.net> Message-ID: On Mar 25, 2008, at 16:10, David Chait wrote: > Understood. But note that another version shift, invalidation of > existing sifr3 resources/fonts can be a headache for some designers > (who might then not upgrade at all). Granted, there's been changes/ > fixes along the way that necessitated rebuilding of files anyway. ;) In terms of the sIFR upgrade path nothing much would change, except of course you'll need CS3. > What does going to F9+AS3 give us? Are there new visual features to > further enhance the sifr-offering? Will that make cmdline, non-FCS3 > tools, a reality? Better code, but that's not really tangible. Perhaps the Flash stuff will become easier to extend, but not many people do so anyway. I guess command line tools would be a big reason, need to figure out if you can do command line sIFR compilation with AS2. > Should those be sifr3, or let someone else tackle them for a > 'sifr4'? Or, that is to say, where IS sifr3 at right now in terms > of features and bugs? Could it be frozen, released, and ONLY > bugfixes, and then go ahead and do your shift to F9+AS3 as 'sifr4'? > Does that win us anything, or are we better off shifting now to F9? Right now the bugs are in the client side, although I need to do a major cleanup of the Flash code anyway. One reason I'd like to do AS3 is that I'd prefer not to work much on sIFR anymore going forward, and a solid version using the latest tools will make it easier for others to chop in. > How much time will it take to migrate over? (real world time...) Provided I have the tools, something like a day. Development time itself is not the limitation of sIFR development though, it's me finding some solid chunks of time to work on it. Especially since the remaining issues need solid work and can't be done on a train ride. A quick look at the release dates of the nightlies showcases this fact. There were no releases between Feb 1st and March 23rd, I spent some time on sIFR these past few days, and I honestly don't know when I can spend time on it again. Of course it doesn't help that I'm working, finishing university and preparing a move to Copenhagen, but still :) > In terms of Adobe's numbers... they are interesting, but only tell a > part of the story. I guess the people who would use F9 for site > development already won't care if sifr3 jumps to F9 -- but for all > the people using 7 or 8, they're at a dead end the moment you > switch. Thus I'm wondering if better, even just for YOUR sanity, to > declare sifr3 final and branch to sifr4 to do the new/real work you > want to do. Is the current code stable, functional, tested enough > that it can be deployed widely? It is stable enough, with the caveat that you keep an eye on developments and upgrade to the final version once it's released. ABC News using 2.0 RC1 more than a year after the release of 2.0 is a good example of how *not* to handle sIFR 3. I intend to keep sIFR 3 as-is, but there's still a few issues that need to be resolved. Who do you mean by people using Flash 7 or 8? In the case of end- users, sIFR uses progressive enhancement, so that's not a real problem. In the case of developers, the big ones should have the Flash tools, but for the smaller developers / hobbyists forcing an upgrade to Flash 9 could be a problem. That's why I want to do F9 + tools. > Those are the sorts of Qs that come to mind. I already appreciate > your efforts driving this technology forward, over a long period. > The reality is that without setting release goals, without setting > versions, milestones, bug releases, sifr3 just keeps hanging in > 'beta', and you probably have a hundred different release versions > floating around on different websites (which is bad, esp if there > are security issues in any of them!). All true, but the unfortunate outcome of how I approach this project, most especially the priority I can give it in my life. > To close... While we're all 'consumers', it's really your baby at > this point. If you want to do F9, go for it -- though I'd still do > it as 3.1 or 4.0 even just to be VERY clear to less-programmer types > the large shift that is occurring. And then target real releases, > go for stability, go for widespread use. Institute a sifr-announce > list (if there isn't one), and make EVERYONE downloading sifr3 sign > up for it so they get notices of bugfixes and security releases (my > guess is not enough folks sub to this list, though I could be > wrong...). And, if there's HUGE benefit to F9 as a shift, in terms > of immediate (<1mo) next release along with tools (F9 change could > 'strand' fonts again... another reason to call it 4.0...), in terms > of new visuals (I love adding visual effects for people who aren't > programmers OR designers...), I'm game. Let's just choose the right > path, timing, naming, to get it adopted well in the industry. It may be my baby, but I'm asking for feedback for a reason ;-) While it's usually possible to upgrade ActionScript code in existing Flash movies using MTASC (this is what I do to develop, and it kept me sane) I don't think many people actually do this. So I'm not seeing possible stranded fonts as a problem. I'm only planning to rewrite the current code into AS3, and not add any new effects etc. Oh, and there is an announce list. Thanks for the comments David! -- Mark From c.coleman at rapidfyre.net Wed Mar 26 15:18:16 2008 From: c.coleman at rapidfyre.net (Charles Coleman) Date: Wed, 26 Mar 2008 08:18:16 -0700 Subject: [sIFR3-dev] sifr3-dev Digest, Vol 24, Issue 1 In-Reply-To: <47E915FE.2070109@comcast.net> References: <47E7A630.2020900@comcast.net> <47E915FE.2070109@comcast.net> Message-ID: I'm sorry, but I have to at least be one voice speaking in support of keeping sifr3 up to date. Mark has made some very valid arguments for using F9+AS3. It's a year old already and considering how long it will be until sifr4 is released, it makes perfect sense to keep up with the times as of at least a year ago. Most reputable companies are using CS3 by now and it's typically those who aren't making a profit that have trouble upgrading because they copied it or got it for free somewhere. As I have seen touted, there are some very large corporations that are using this piece of software and they (as well as myself a small company) look at things with older code as outdated and tend to look elsewhere. To increase your market share and support the advancement of technology, please us F9+AS3! ----- Charles Coleman, President/CEO Rapidfyre, Inc 509.526.5268 888.297.3973 http://www.rapidfyre.net -----Original Message----- From: sifr3-dev-bounces at lists.novemberborn.net [mailto:sifr3-dev-bounces at lists.novemberborn.net] On Behalf Of David Chait Sent: Tuesday, March 25, 2008 8:11 AM To: Mark Wubben Cc: sifr3-dev at lists.novemberborn.net Subject: Re: [sIFR3-dev] sifr3-dev Digest, Vol 24, Issue 1 Understood. But note that another version shift, invalidation of existing sifr3 resources/fonts can be a headache for some designers (who might then not upgrade at all). Granted, there's been changes/fixes along the way that necessitated rebuilding of files anyway. ;) What does going to F9+AS3 give us? Are there new visual features to further enhance the sifr-offering? Will that make cmdline, non-FCS3 tools, a reality? Should those be sifr3, or let someone else tackle them for a 'sifr4'? Or, that is to say, where IS sifr3 at right now in terms of features and bugs? Could it be frozen, released, and ONLY bugfixes, and then go ahead and do your shift to F9+AS3 as 'sifr4'? Does that win us anything, or are we better off shifting now to F9? How much time will it take to migrate over? (real world time...) In terms of Adobe's numbers... they are interesting, but only tell a part of the story. I guess the people who would use F9 for site development already won't care if sifr3 jumps to F9 -- but for all the people using 7 or 8, they're at a dead end the moment you switch. Thus I'm wondering if better, even just for YOUR sanity, to declare sifr3 final and branch to sifr4 to do the new/real work you want to do. Is the current code stable, functional, tested enough that it can be deployed widely? Those are the sorts of Qs that come to mind. I already appreciate your efforts driving this technology forward, over a long period. The reality is that without setting release goals, without setting versions, milestones, bug releases, sifr3 just keeps hanging in 'beta', and you probably have a hundred different release versions floating around on different websites (which is bad, esp if there are security issues in any of them!). To close... While we're all 'consumers', it's really your baby at this point. If you want to do F9, go for it -- though I'd still do it as 3.1 or 4.0 even just to be VERY clear to less-programmer types the large shift that is occurring. And then target real releases, go for stability, go for widespread use. Institute a sifr-announce list (if there isn't one), and make EVERYONE downloading sifr3 sign up for it so they get notices of bugfixes and security releases (my guess is not enough folks sub to this list, though I could be wrong...). And, if there's HUGE benefit to F9 as a shift, in terms of immediate (<1mo) next release along with tools (F9 change could 'strand' fonts again... another reason to call it 4.0...), in terms of new visuals (I love adding visual effects for people who aren't programmers OR designers...), I'm game. Let's just choose the right path, timing, naming, to get it adopted well in the industry. -d Mark Wubben wrote: > On Mar 24, 2008, at 14:01, David Chait wrote: >> My concerns are: >> - moving target to work with. ;) (every time I think about integrating >> a new version, I get an email with a new release with big changes! ;) ) > > Yea I know. This was the last JavaScript refactoring I had planned > though, so other than fixing bugs it shouldn't change (too much...). > >> - getting to a final, stable release that people can/will use for >> YEARS. get '3' out the door, and work on '3.1', or '4'. > > Oh yes. Get v3 out of the door, and then preferably find someone else > for subsequent version. > >> - shifting Flash reqs once again (early in sifr3 dev was the shift to >> 7+8, right?), and losing a ton of intermediary installed base for which >> sifr3 would give improvements over sifr2 for designers... > > Fair point. However, you need to take the long development history of > v3 into account. I mean, I started work on it like 2.5 years ago, when > Flash 8 was still brand new. These days, even Flash 9 isn't very new > anymore. Adobe's stats from last December [1] show 93 - 95% market > penetration, and this will only be higher by the time v3 is finally > ready ;-) I'm also thinking ahead, ActionScript 3 is the way to go for > Flash programming, and it may be a smart investment for future > development to have an AS3 version. > > Personally I'm not worried about development time regarding a port to > AS3, I can do that in less than a day. A bigger problem is the install > base of Flash IDEs, which brings us to: > >> I'm a big proponent of tools for generating the sifr movies that don't >> require CSn... but I'd like to see sifr3 continue to support some >> earlier flash variants though, unless there's strong data to drop >> backwards support... ;) > > I think that if we have the tools it shouldn't matter much, especially > going forward. Do you think my data [1] is strong enough? > > Thanks for your comments, as always, > > [1]: > http://www.adobe.com/products/player_census/flashplayer/version_penetrat ion.html > > > -- > Mark > > _______________________________________________ sifr3-dev mailing list sifr3-dev at lists.novemberborn.net http://lists.novemberborn.net/mailman/listinfo/sifr3-dev