Re: [flexcoders] Re: AIR vs DLL vs. External code?
On 8/28/07, dorkie dork from dorktown [EMAIL PROTECTED] wrote: this is just my opinion but i don't think adobe wants you to code outside of the box. i don't think they'll give you that much more access to the system. for one, security. any security issues would slow down adoption. two, cross compatibility. cross compatibility is one of the enticing features for developing for flash. you can write something that runs anywhere the flash player is available. any browser, any os it will look the same and run the same (so is the goal). Yes and no. Director is cross platform, third party extendable, network integrated and secure (for Verisigned shockwave xtras) and has been for nearly a decade. So no - allowing access to the host OS does not implicitly imply security or cross platform issues. Cross platform could be restricted by the developer using a single platform Xtra, however that was purely at the discretion of the developer, the key point being that the developer had a choice. It was also the developers choice to stay platform neutral and publish to mac/pc/web from the single project. But i do agree with you that they probably wont offer too much more than they already have partly because they already have a product that does it and secondly there are so many other things that would give them a greater benefit than platform integration which is already provided in some form by wrapper apps etc. Regards, Nik
Re: [flexcoders] Re: AIR vs DLL vs. External code?
hank williams wrote: lol. You cant take my statement 100% literally. Yeah I know this is a programmers forum but how about allow for a little err... creative license. Fair enough. ;) Really only a handful of companies today make money selling software, and they include Microsoft, Adobe, and a few others. In fact developer tools will probably be one of the last categories to go totally online. But most application categories are moving to a software as service model. Software as a service feels like a move back to the 'dumb client' model of mainframes. Even if it does take off en masse, I don't expect it to replace traditional desktop apps. -- Jeffry Houser, Technical Entrepreneur, Software Developer, Author, Recording Engineer AIM: Reboog711 | Phone: 1-203-379-0773 -- My Company: http://www.dot-com-it.com My Podcast: http://www.theflexshow.com My Blog: http://www.jeffryhouser.com
Re: [flexcoders] Re: AIR vs DLL vs. External code?
Fair enough, good point. I'd say 99.9% of my usage with Flex Builder / Eclipse is non-connected, though. Tony Alves wrote: Jeffry, What about the updates in Flex Builder? Updates check the internet. I do agree that not all apps are connected to the internet. Jeffry Houser wrote: Interesting perspective. I believe it is incorrect. I use many desktop applications that do not need /have connectivity. Flex Builder is one great example. -- Jeffry Houser, Technical Entrepreneur, Software Developer, Author, Recording Engineer AIM: Reboog711 | Phone: 1-203-379-0773 -- My Company: http://www.dot-com-it.com My Podcast: http://www.theflexshow.com My Blog: http://www.jeffryhouser.com
Re: [flexcoders] Re: AIR vs DLL vs. External code?
Software as a service feels like a move back to the 'dumb client' model of mainframes. Even if it does take off en masse, I don't expect it to replace traditional desktop apps. Naw dude, not at all. Connected or software as service doesn't have to mean bad terminal like software, though until recently I would agree that it did. The software in browser thing was the bane of my existence for the last 10 years. Browser based software rolled back the progress we had made in good user interface design in the 80's and 90's. Imagine being able to scroll your toolbar off the top of the screen, as is standard design in todays web pages. Just imagine if you had to *scroll* to get to the adobe illustrator tool bar because it was off screen. The browser took us back into the interface stone age for the last 10 years. Unfortunately, not withstanding this fact, many major apps started to appear in browsers using these bastardized user interfaces driven by the fact that we did not have tools like flex and AJAX and now AIR. Now most standard desktop apps are being re-architected around connectedness, whether it is from a desktop codebase or a web based code base. The reason this is happening (all the big software companies have either launched such products or have announced them) is because software is just better when it is connected. If you lament the notion or disagree with the idea that most desktop productivity apps will begin to be designed around internet awareness and/or collaboration we should revist this in another 18 months. You pick the place - looser buys the beer :) Hank
Re: [flexcoders] Re: AIR vs DLL vs. External code?
hank williams wrote: Software as a service feels like a move back to the 'dumb client' model of mainframes. Even if it does take off en masse, I don't expect it to replace traditional desktop apps. Naw dude, not at all. Connected or software as service doesn't have to mean bad terminal like software, though until recently I would agree that it did. When most people talk about Software as a service they use Google Docs as a prime example. That's just software in a browser, and I don't ever expect it (or Buzzword) to replace my MS Word. However, if you are using 'software as a service' to include something like iTunes ( Which is Softare and Services), then that makes a lot more sense to me. If you lament the notion or disagree with the idea that most desktop productivity apps will begin to be designed around internet awareness and/or collaboration we should revist this in another 18 months. You pick the place - looser buys the beer :) I have no doubt they will. I'm just not sold on the benefits of such an environment yet. Feel free to call me a skeptic. -- Jeffry Houser, Technical Entrepreneur, Software Developer, Author, Recording Engineer AIM: Reboog711 | Phone: 1-203-379-0773 -- My Company: http://www.dot-com-it.com My Podcast: http://www.theflexshow.com My Blog: http://www.jeffryhouser.com
Re: [flexcoders] Re: AIR vs DLL vs. External code?
No arguments. ;) Tony Alves wrote: Hello Jeffry, I agree with you. I do not see a benefit of running a word processor in an online application unless it is maybe to edit some content in the application. I really do not want to run my word processor in a browser application either. Do I need a word processor to be cross platform (Win, Linux, Mac)? Probably not. What I would like to do is be able to have some other server store my documents and back them up allowing me to categorize them and share them with my colleagues online. This is the benefit of online services that I think will be in demand. Another example that drives me crazy right now is my online banking. I love online banking. I hate the applications that they use to administer this great online service. There are an infinite number of examples of online services that would run applications that you would not want installed on your client machine. If I had to install every one of them that I liked, I would have to get another tera-byte of disk and delete all my mp3's :( Not to mention the time it would take to install the upgrades when they had bug fixes. You are right, software as a service model is not really going to work for most users. But, online services using RIA will definitely be the future. Until lately, we did not have a good framework for creating good user interfaces for data driven applications on the internet. Client applications are not going away either. We are just saying that there is a HUGE demand for online applications that WORK well. A good way to prove this is to look at the number of online applications already running today. They would greatly benefit from a Flex (or other) upgrade. Salesforce.com is a perfect example of an online service model that works. They are very successful and even realize the need for Rich Internet Applications. They have put a ton of time into creating an API in actionscript. And I must say, it rocks. Regards, Tony Jeffry Houser wrote: hank williams wrote: Software as a service feels like a move back to the 'dumb client' model of mainframes. Even if it does take off en masse, I don't expect it to replace traditional desktop apps. Naw dude, not at all. Connected or software as service doesn't have to mean bad terminal like software, though until recently I would agree that it did. When most people talk about Software as a service they use Google Docs as a prime example. That's just software in a browser, and I don't ever expect it (or Buzzword) to replace my MS Word. However, if you are using 'software as a service' to include something like iTunes ( Which is Softare and Services), then that makes a lot more sense to me. If you lament the notion or disagree with the idea that most desktop productivity apps will begin to be designed around internet awareness and/or collaboration we should revist this in another 18 months. You pick the place - looser buys the beer :) I have no doubt they will. I'm just not sold on the benefits of such an environment yet. Feel free to call me a skeptic. -- Jeffry Houser, Technical Entrepreneur, Software Developer, Author, Recording Engineer AIM: Reboog711 | Phone: 1-203-379-0773 -- My Company: http://www.dot-com-it.com http://www.dot-com-it.com My Podcast: http://www.theflexshow.com http://www.theflexshow.com My Blog: http://www.jeffryhouser.com http://www.jeffryhouser.com -- Jeffry Houser, Technical Entrepreneur, Software Developer, Author, Recording Engineer AIM: Reboog711 | Phone: 1-203-379-0773 -- My Company: http://www.dot-com-it.com My Podcast: http://www.theflexshow.com My Blog: http://www.jeffryhouser.com
Re: [flexcoders] Re: AIR vs DLL vs. External code?
this is just my opinion but i don't think adobe wants you to code outside of the box. i don't think they'll give you that much more access to the system. for one, security. any security issues would slow down adoption. two, cross compatibility. cross compatibility is one of the enticing features for developing for flash. you can write something that runs anywhere the flash player is available. any browser, any os it will look the same and run the same (so is the goal). i'm not saying being able to call a dll wouldn't be helpful or isn't needed but the minute you add support for a proprietary os api you lose cross compatibility. adobe is open about their plans for air: https://bugs.adobe.com/confluence/display/ADOBE/Home https://bugs.adobe.com/confluence/display/ADOBE/Flex+3+Planning if it is not listed you just need to ask, http://bugs.adobe.com/flex these links include air related information On 8/26/07, droponrcll [EMAIL PROTECTED] wrote: --- In flexcoders@yahoogroups.com flexcoders%40yahoogroups.com, hank williams [EMAIL PROTECTED] wrote: On 8/25/07, Jeffry Houser [EMAIL PROTECTED] wrote: hank williams wrote: So in your mind, Adobe's goal of being cross platform should be abandoned since there is no way to do cross-platform COM? Would you find it acceptable if it allowed you to do Mac only desktop stuff or does windows only compatible == desktop software? I think Adobe should provide hooks that allow extension, for instance by Java. If it so happens that a third-party or homegrown extension *happens* not to be cross-platform, AIR itself will still be cross- platform. It shouldn't be Adobe's business to enforce that everything that could ever be used by AIR would have to be cross- platform. For example, both Authorware and Director (Adobe's desktop application building programs) are both cross-platform but allow extension via Xtras and other means. Not all of those Xtras are cross-platform, but developers still find them incredibly useful, either because they are only working on one platform or because they can work around the gap in some other way on the other platform. You cant really compare AIR to authorware and director. These were both very thinly deployed tools (compared to flash) Shouldn't we be comparing them to AIR in this case? I'd be willing to bet that AIR's deployment (at this stage) is very thinly deployed. Yes, AIR has Flash Player embedded, but AIR != Flash Actually, AIR uses special non publicly available pieces of the flash platform to make installing totally seamless. When you click on an AIR app to download, it it leverages this not publicly available stuff to download the AIR runtime in the background. So they are leveraging the presence of flash to facilitate the installation of the runtime. This is a *big* deal and feels very different from downloading an exe in explorer. If it's not a big deal for your apps you can, as I said, just use one of the many flash to exe projectors out there. Also, Director and Authorware cant really be compared to AIR because neither of them was based on a runtime separate from the application being installed on the users computer. Being a completely self contained download made it more appropriate to allow these tools to bring DLLs or Xtras with them. Anything can be bundled in a stand-alone download, but AIR apps are not exe's and are dependent on the AIR runtime. This is a critical architectural difference. I disagree. I am not certain how Director works, since I've never used it except to make movies that were then integrated into Authorware, but Authorware has the ability to either incorporate the runtime into the content file as a new exe or to provide it separately. The fact that the AIR team chose only one of these strategies is not compelling to me. I think they may eventually add additional layers of access to the system, but I doubt that they will ever go as far as you would like because the responsibility is too great for a browser connected tool. I wouldn't consider AIR a browser connected tool. It does have an embedded browser, but... The ability to integrate with the local system (Via an execute type command) is almost mandatory for non-connected applications. It sounds like you are saying that there is no market for AIR. Based on the general reaction from the developer community, I would have to disagree. Of course perhaps you are just trying to say that given that AIR's focus on occasionally connected applications, that there isnt such a need for access to DLLs and such. If so I would whole heartedly agree. At this time, it does not appear that AIR fits that market very well (nor are they targeting the market.. ) If you need to run DLLs
Re: [flexcoders] Re: AIR vs DLL vs. External code?
Actually, AIR uses special non publicly available pieces of the flash platform to make installing totally seamless. When you click on an AIR app to download, it it leverages this not publicly available stuff to download the AIR runtime in the background. That all sounds like heresay to me, since right now you have to download and install the SDK separately before you can install an AIR app. Hmm… perhaps. I guess it depends on your definition of hearsay. If it means that Adobe said it, and there are working apps that demonstrate it, but you just choose not to believe it then perhaps so. More specifically, At this URL: http://labs.adobe.com/technologies/air/samples/ There are AIR sample applications. The first one is labeled as follows: Install Now In order to run Employee directory this installer will also setup Adobe AIR. When you click on it, in the little flash area it says: Installing this application requires the Adobe Integrated Runtime (AIR), which will also be downloaded and installed. Press yes to continue When you do click, if the machine you are on doesn't yet have AIR, as the test machine I used did not, it did in fact install AIR. I wonder about non-web based distribution? It stated in an FAQ somewhere on the labs site that the SDK will be distributable for CD projects. Obviously in such a situation you won't be going to the web. AIR apps *cannot* currently be distributed on CD. The SDK can, just as the Flex SDK can or any library or compiler can. The SDK is just libraries, and distributing them via CD does not mean that the resulting apps can be distributed via CD. I believe I read they intend to allow this at some point in the future but not before 1.0. I wouldn't consider AIR a browser connected tool. It does have an embedded browser, but... The ability to integrate with the local system (Via an execute type command) is almost mandatory for non-connected applications. It sounds like you are saying that there is no market for AIR. I'm saying that there is no market for AIR in non-connected desktop applications. -- Jeffry Houser, Technical Entrepreneur, Software Developer, Author, Recording Engineer AIM: Reboog711 | Phone: 1-203-379-0773 -- My Company: http://www.dot-com-it.com My Podcast: http://www.theflexshow.com My Blog: http://www.jeffryhouser.com -- Flexcoders Mailing List FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com Yahoo! Groups Links * To visit your group on the web, go to: http://groups.yahoo.com/group/flexcoders/ * Your email settings: Individual Email | Traditional * To change settings online go to: http://groups.yahoo.com/group/flexcoders/join (Yahoo! ID required) * To change settings via email: mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] * To unsubscribe from this group, send an email to: [EMAIL PROTECTED] * Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
Re: [flexcoders] Re: AIR vs DLL vs. External code?
I'm saying that there is no market for AIR in non-connected desktop applications. -- I think in 2007 we can almost safely say there is no market for *any* non-connected desktop applications, with or without AIR. Hank
Re: [flexcoders] Re: AIR vs DLL vs. External code?
hank williams wrote: I think in 2007 we can almost safely say there is no market for *any* non-connected desktop applications, with or without AIR. Bold words... Cheers, Claus.
Re: [flexcoders] Re: AIR vs DLL vs. External code?
On Aug 26, 2007, at 10:52 AM, hank williams wrote: AIR apps *cannot* currently be distributed on CD. The SDK can, just as the Flex SDK can or any library or compiler can. The SDK is just libraries, and distributing them via CD does not mean that the resulting apps can be distributed via CD. I believe I read they intend to allow this at some point in the future but not before 1.0. It looks like it will be possible to distribute AIR apps (that include the runtime) with v1.0 according to the faq: http://labs.adobe.com/wiki/index.php/ AIR:Developer_FAQ#Will_developers_be_able_to_distribute_the_Adobe_AIR_in staller_with_their_applications.3F Thijs
Re: [flexcoders] Re: AIR vs DLL vs. External code?
The issue I was referring to was whether it would be possible to do so without being online and Via CD. My understanding was that this was not the case. These two concepts I suspect are not in conflict. The FAQ merely says that people will be able to write their own installers. Writing your own installer is not necessarily the same thing as being able to install an app off line via CD though there is certainly at least good reason to question my recollection/understanding. I think I remember mike chambers talking about this but I am unable to cite any references. Perhaps someone on the team can clarify. Regards, Hank On 8/26/07, Thijs Triemstra | Collab [EMAIL PROTECTED] wrote: On Aug 26, 2007, at 10:52 AM, hank williams wrote: AIR apps *cannot* currently be distributed on CD. The SDK can, just as the Flex SDK can or any library or compiler can. The SDK is just libraries, and distributing them via CD does not mean that the resulting apps can be distributed via CD. I believe I read they intend to allow this at some point in the future but not before 1.0. It looks like it will be possible to distribute AIR apps (that include the runtime) with v1.0 according to the faq: http://labs.adobe.com/wiki/index.php/ AIR:Developer_FAQ#Will_developers_be_able_to_distribute_the_Adobe_AIR_in staller_with_their_applications.3F Thijs
Re: [flexcoders] Re: AIR vs DLL vs. External code?
Interesting perspective. I believe it is incorrect. I use many desktop applications that do not need /have connectivity. Flex Builder is one great example. hank williams wrote: I'm saying that there is no market for AIR in non-connected desktop applications. -- I think in 2007 we can almost safely say there is no market for *any* non-connected desktop applications, with or without AIR. Hank -- Jeffry Houser, Technical Entrepreneur, Software Developer, Author, Recording Engineer AIM: Reboog711 | Phone: 1-203-379-0773 -- My Company: http://www.dot-com-it.com My Podcast: http://www.theflexshow.com My Blog: http://www.jeffryhouser.com
Re: [flexcoders] Re: AIR vs DLL vs. External code?
hank williams wrote: Actually, AIR uses special non publicly available pieces of the flash platform to make installing totally seamless. When you click on an AIR app to download, it it leverages this not publicly available stuff to download the AIR runtime in the background. That all sounds like heresay to me, since right now you have to download and install the SDK separately before you can install an AIR app. Hmm… perhaps. I guess it depends on your definition of hearsay. If it means that Adobe said it, and there are working apps that demonstrate it, I was unaware that functionality was out in the wild. They've talked about, I've never seen it demonstrated. AIR apps *cannot* currently be distributed on CD. I'm unsure of specifics, but why not? It will be a 'version 1' feature, per this FAQ: http://labs.adobe.com/wiki/index.php/AIR:Developer_FAQ#Can_I_create_CD-ROM_or_Kiosk_applications_that_leverage_Adobe_AIR.3F If they have the automated installer built, why can't it be put onto a CD? -- Jeffry Houser, Technical Entrepreneur, Software Developer, Author, Recording Engineer AIM: Reboog711 | Phone: 1-203-379-0773 -- My Company: http://www.dot-com-it.com My Podcast: http://www.theflexshow.com My Blog: http://www.jeffryhouser.com -- Flexcoders Mailing List FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com Yahoo! Groups Links * To visit your group on the web, go to: http://groups.yahoo.com/group/flexcoders/ * Your email settings: Individual Email | Traditional * To change settings online go to: http://groups.yahoo.com/group/flexcoders/join (Yahoo! ID required) * To change settings via email: mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] * To unsubscribe from this group, send an email to: [EMAIL PROTECTED] * Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
Re: [flexcoders] Re: AIR vs DLL vs. External code?
AIR apps *cannot* currently be distributed on CD. I'm unsure of specifics, but why not? It will be a 'version 1' feature, per this FAQ: http://labs.adobe.com/wiki/index.php/AIR:Developer_FAQ#Can_I_create_CD-ROM_or_Kiosk_applications_that_leverage_Adobe_AIR.3F If they have the automated installer built, why can't it be put onto a CD? Ah you found the faq point that clarifies my confusion. You cant run from CD but you can install from a CD. Hank
Re: [flexcoders] Re: AIR vs DLL vs. External code?
Jeffry, What about the updates in Flex Builder? Updates check the internet. I do agree that not all apps are connected to the internet. Jeffry Houser wrote: Interesting perspective. I believe it is incorrect. I use many desktop applications that do not need /have connectivity. Flex Builder is one great example.
Re: [flexcoders] Re: AIR vs DLL vs. External code?
I disagree. I am not certain how Director works, since I've never used it except to make movies that were then integrated into Authorware, but Authorware has the ability to either incorporate the runtime into the content file as a new exe or to provide it separately. The fact that the AIR team chose only one of these strategies is not compelling to me. Everything aint for everybody. But regarding the runtime issue, there is a big difference between a shipping two separate files i.e. a library and an application, and shipping a common runtime with the intent to install that runtime on every computer on the planet. Director never had that has a goal, and it would never have been a reasonable one if they had. IMO, it does not make sense for Adobe to continue to develop Director when AIR and Flash have the potential ability to replace it. Adobe has already stopped development on Director, and I can tell you they will never manage to convince Authorware users to pick up Director, regardless of its innate capabilities, because we believe its days are also numbered. However, for the replacement to happen, Adobe will have to add more capability to AIR. lol. Do you really think Adobe cares about supporting or capturing the Director or Authorware markets. They will never admit it publicly, but they are irrelevant. They are certainly not designing AIR with the idea of making sure that Director or Authorware users are happy. Hank
Re: [flexcoders] Re: AIR vs DLL vs. External code?
lol. You cant take my statement 100% literally. Yeah I know this is a programmers forum but how about allow for a little err... creative license. There is almost nothing that is 100% true. But there are *very* few programs that are sold today that do not have a connected component. I used to write software that I sold in a box that was sold a compUSA, That business is all but gone. In fact there are very few programs sold today in the desktop market at all. Years ago I could make money selling software. Today one must sell services driven by software. Really only a handful of companies today make money selling software, and they include Microsoft, Adobe, and a few others. In fact developer tools will probably be one of the last categories to go totally online. But most application categories are moving to a software as service model. Microsoft Works is now free and makes money by displaying ads. Even intuit is moving towards an online subscription based version of quicken. The Microsoft Office franchise is under attack by Google office and other online applications and ever microsoft has said the next major release of office will be a connected application. The disconnected application is *dying*. Hank On 8/26/07, Jeffry Houser [EMAIL PROTECTED] wrote: Interesting perspective. I believe it is incorrect. I use many desktop applications that do not need /have connectivity. Flex Builder is one great example. hank williams wrote: I'm saying that there is no market for AIR in non-connected desktop applications. -- I think in 2007 we can almost safely say there is no market for *any* non-connected desktop applications, with or without AIR. Hank -- Jeffry Houser, Technical Entrepreneur, Software Developer, Author, Recording Engineer AIM: Reboog711 | Phone: 1-203-379-0773 -- My Company: http://www.dot-com-it.com My Podcast: http://www.theflexshow.com My Blog: http://www.jeffryhouser.com
Re: [flexcoders] Re: AIR vs DLL vs. External code?
--- In flexcoders@yahoogroups.com, hank williams [EMAIL PROTECTED] wrote: So in your mind, Adobe's goal of being cross platform should be abandoned since there is no way to do cross-platform COM? Would you find it acceptable if it allowed you to do Mac only desktop stuff or does windows only compatible == desktop software? I think Adobe should provide hooks that allow extension, for instance by Java. If it so happens that a third-party or homegrown extension *happens* not to be cross-platform, AIR itself will still be cross- platform. It shouldn't be Adobe's business to enforce that everything that could ever be used by AIR would have to be cross- platform. For example, both Authorware and Director (Adobe's desktop application building programs) are both cross-platform but allow extension via Xtras and other means. Not all of those Xtras are cross-platform, but developers still find them incredibly useful, either because they are only working on one platform or because they can work around the gap in some other way on the other platform. You cant really compare AIR to authorware and director. These were both very thinly deployed tools (compared to flash) and they never had runtimes that were, essentially, built into the operating system (as flash effectively is at 98% or 99%). The responsibility that adobe shoulders in making tools that do things like seamlessly download, auto update, etc and dont crash the system are substantial. They cant afford to use their position to facilitate installation of 3rd party DLLs that can easily crash the local system. I think they may eventually add additional layers of access to the system, but I doubt that they will ever go as far as you would like because the responsibility is too great for a browser connected tool. The good news is there are already so many alternatives if all you really want to do is build an exe, such as Zinc, screenweaver hx, etc. There is absolutely nothing standing in the way of making fully functional exes. I am personally happy to trade full system level access in return for having a pre-installed runtime that leverages the seamless flash download and upgrade system. Hank
Re: [flexcoders] Re: AIR vs DLL vs. External code?
hank williams wrote: So in your mind, Adobe's goal of being cross platform should be abandoned since there is no way to do cross-platform COM? Would you find it acceptable if it allowed you to do Mac only desktop stuff or does windows only compatible == desktop software? I think Adobe should provide hooks that allow extension, for instance by Java. If it so happens that a third-party or homegrown extension *happens* not to be cross-platform, AIR itself will still be cross- platform. It shouldn't be Adobe's business to enforce that everything that could ever be used by AIR would have to be cross- platform. For example, both Authorware and Director (Adobe's desktop application building programs) are both cross-platform but allow extension via Xtras and other means. Not all of those Xtras are cross-platform, but developers still find them incredibly useful, either because they are only working on one platform or because they can work around the gap in some other way on the other platform. You cant really compare AIR to authorware and director. These were both very thinly deployed tools (compared to flash) Shouldn't we be comparing them to AIR in this case? I'd be willing to bet that AIR's deployment (at this stage) is very thinly deployed. Yes, AIR has Flash Player embedded, but AIR != Flash I think they may eventually add additional layers of access to the system, but I doubt that they will ever go as far as you would like because the responsibility is too great for a browser connected tool. I wouldn't consider AIR a browser connected tool. It does have an embedded browser, but... The ability to integrate with the local system (Via an execute type command) is almost mandatory for non-connected applications. At this time, it does not appear that AIR fits that market very well (nor are they targeting the market.. ) If you need to run DLLs / COM / etc... then AIR probably isn't a good choice. -- Jeffry Houser, Technical Entrepreneur, Software Developer, Author, Recording Engineer AIM: Reboog711 | Phone: 1-203-379-0773 -- My Company: http://www.dot-com-it.com My Podcast: http://www.theflexshow.com My Blog: http://www.jeffryhouser.com
Re: [flexcoders] Re: AIR vs DLL vs. External code?
On 8/25/07, Jeffry Houser [EMAIL PROTECTED] wrote: hank williams wrote: So in your mind, Adobe's goal of being cross platform should be abandoned since there is no way to do cross-platform COM? Would you find it acceptable if it allowed you to do Mac only desktop stuff or does windows only compatible == desktop software? I think Adobe should provide hooks that allow extension, for instance by Java. If it so happens that a third-party or homegrown extension *happens* not to be cross-platform, AIR itself will still be cross- platform. It shouldn't be Adobe's business to enforce that everything that could ever be used by AIR would have to be cross- platform. For example, both Authorware and Director (Adobe's desktop application building programs) are both cross-platform but allow extension via Xtras and other means. Not all of those Xtras are cross-platform, but developers still find them incredibly useful, either because they are only working on one platform or because they can work around the gap in some other way on the other platform. You cant really compare AIR to authorware and director. These were both very thinly deployed tools (compared to flash) Shouldn't we be comparing them to AIR in this case? I'd be willing to bet that AIR's deployment (at this stage) is very thinly deployed. Yes, AIR has Flash Player embedded, but AIR != Flash Actually, AIR uses special non publicly available pieces of the flash platform to make installing totally seamless. When you click on an AIR app to download, it it leverages this not publicly available stuff to download the AIR runtime in the background. So they are leveraging the presence of flash to facilitate the installation of the runtime. This is a *big* deal and feels very different from downloading an exe in explorer. If it's not a big deal for your apps you can, as I said, just use one of the many flash to exe projectors out there. Also, Director and Authorware cant really be compared to AIR because neither of them was based on a runtime separate from the application being installed on the users computer. Being a completely self contained download made it more appropriate to allow these tools to bring DLLs or Xtras with them. Anything can be bundled in a stand-alone download, but AIR apps are not exe's and are dependent on the AIR runtime. This is a critical architectural difference. I think they may eventually add additional layers of access to the system, but I doubt that they will ever go as far as you would like because the responsibility is too great for a browser connected tool. I wouldn't consider AIR a browser connected tool. It does have an embedded browser, but... The ability to integrate with the local system (Via an execute type command) is almost mandatory for non-connected applications. It sounds like you are saying that there is no market for AIR. Based on the general reaction from the developer community, I would have to disagree. Of course perhaps you are just trying to say that given that AIR's focus on occasionally connected applications, that there isnt such a need for access to DLLs and such. If so I would whole heartedly agree. At this time, it does not appear that AIR fits that market very well (nor are they targeting the market.. ) If you need to run DLLs / COM / etc... then AIR probably isn't a good choice. This is clearly true. Hank
Re: [flexcoders] Re: AIR vs DLL vs. External code?
hank williams wrote: You cant really compare AIR to authorware and director. These were both very thinly deployed tools (compared to flash) Shouldn't we be comparing them to AIR in this case? I'd be willing to bet that AIR's deployment (at this stage) is very thinly deployed. Yes, AIR has Flash Player embedded, but AIR != Flash Actually, AIR uses special non publicly available pieces of the flash platform to make installing totally seamless. When you click on an AIR app to download, it it leverages this not publicly available stuff to download the AIR runtime in the background. That all sounds like heresay to me, since right now you have to download and install the SDK separately before you can install an AIR app. I wonder about non-web based distribution? It stated in an FAQ somewhere on the labs site that the SDK will be distributable for CD projects. Obviously in such a situation you won't be going to the web. I wouldn't consider AIR a browser connected tool. It does have an embedded browser, but... The ability to integrate with the local system (Via an execute type command) is almost mandatory for non-connected applications. It sounds like you are saying that there is no market for AIR. I'm saying that there is no market for AIR in non-connected desktop applications. -- Jeffry Houser, Technical Entrepreneur, Software Developer, Author, Recording Engineer AIM: Reboog711 | Phone: 1-203-379-0773 -- My Company: http://www.dot-com-it.com My Podcast: http://www.theflexshow.com My Blog: http://www.jeffryhouser.com
