I was writing a comment but it became more longer, so I'm going to make a post instead.

Posted by: aSH at February 7, 2004 09:16 PM

American's unfortunately only come in the standard model's which usually only know 1 language.

I know 4:
- English
- Aussie
- Ebonics
- l33t

For a version 1, I think choosing 6.0.65.0, at the time of Central's inception, was a good idea. It's a solid player, and they have a lot more proliferation than with Flash 7. Makes a better testing ground, anyway.

Central is very secure; you have the security of the Flash sandbox, MD5, and SSL...or was that https?

Fourth and fifth thing: I agree. I think branding is a very important issue. I think the eventual goal is to compete with Screenweaver (I think) so you'd be able to get alot more control back on your branding. As for the size change, Shell.requestSizeChange, and pass in the width and height you were last at.

Seventh: Fair enough. I vote you wait just a little longer.

Eight: I agree on the large companies; unless they offer a standalone, I don't know how a few friends could even use it as their firewalls and proxies are all lame. However, I think smaller users would.

You make a ton of great points. I hope I've helped with a few, although, I know that I can't really tackle your main ones.

Posted by: JesterXL at February 7, 2004 09:17 PM

Well I change my mind because finally I don't have time to write an entry.

>>First thing
Yes it's in english, only english... at the moment. It could take some time to get the localizations. But you can start to build or migrate your apps and then the only thing that you need to do is update your product.xml file. With Central you can do instant updates, and you don't have to worry about cross-plataform or cross-browser issues. I 'm waiting the french localization to deploy. But I'm not waiting the french localization to develop and migrate. Sooner or later, you'll find you in the learning process... the sooner, the better.
>>Second thing
It's in flash 6 because the central team started before the f7. It's possible that the f7 support will be included in the next release of Central, in fact, more than possible IMHO.
>>Third thing
It depends what kind of apps you are talking about, the apps that your client wants (online, desktop...). Central is not only a client. Central has many unique features and facilities. With Central you have more integration with the native operating system, which is something more in accordance with RIA's but it doesn't means that it's a spyware. The browser is a "stateless" client, Central is a truly stateful client... But you said that central is in the list of things not secure, I would like to hear more about that... It's possible that running a windows operating system could be more risky that Central.
"I don't want or need the extra work that is required to justify why I have to use another company's framework, design/application to hold my application"
What about the browser? The difference with Central at that point is that your "favorites" apps are in the "toolbar", and you can colapse that toolbar btw.
>>Fourth thing
Well, it could be more "light" the macromedia logos, but once again, with browsers you have the same issue then...
>>Fifht thing
Central is currently in it's v.1... "Why would I as a consumer need or want to install Central?" well, because the browser is short for RIA's and the UX with Central makes the difference
>>Sixth thing
With central you have easy updates, distribution and listing in the app finder. I believe is more expensive other schemes.
>>Seventh thing
Central, flash, director... can disappear, but we still work with them.
>>Eighth thing
Once again, it deepends of the need of each company. If you need a stateful client, RIA's working online and offline and colaborating, for instance, Central is the way to go.

Posted by: aSH at February 7, 2004 09:48 PM

Jesse, thanks for popping in with your comments. I like the wide range of languages you got there :)

For a version 1, yes I can understand that it's 6.0.65 I guess.

When I say secure, I don't mean flash sandbox, that is reasonably covered on MM's site. I haven't seen any white papers or articles on the Security of Central. I mean details. This is due to the fact that the app must connect up to MM's server, what happens at that point? What information is available? When a customer buys a product what is passed between all involved? When installing Central, where from do I have to download it from, why, and what information is transferred between the systems? Why isn't Central allowed to be installed by local install? None of these questions have to or should be answered on this blog, I would much prefer to see a proper white paper from MM on all of these details and more. What would be more? I don't know, but I can not go to my architecure manager with the info that is provided right now, he'd kick my ass out his door, down the steps of the building and into the nearest ocean, smack me around with a dead fish then.....

If Shell.requestSizeChange is available, then why don't developers use it? When I go into the dev chat, and then wander off to the blog reader it changes sizes on me. Then when I go back to chat it doesn't move, when I shut it down and reload it again it's different. This inconsistency leads me to believe that it is up to the developer to put these functions in. This is not central's doing, which means it's not much different than using my own app. It needs to be a central function I think or at the very least a mandatory function that should be installed at all times.

Thanks for your words though, it gives me some food for thought, and lets me know that my worries weren't unfounded.

aSH, thanks for the comments, let me go over them one by one here.

First thing:
I agree with you. I do have to wait for localization, but... that's the problem. What happens when I pour lots of energy into my app, and it never gets localized? What happens (because I most certainly can't test it now) when it does get localized, and it doesn't work? Things like these are risks that don't NEED to be taken. If I wanted to take them I suppose I could, but it's not just up to me, and I cannot justify these risks right now. Your explanation is not something I could take to my manager or colleagues.

Second thing:
About flash 6, I understand. We'll see what happens in the future, though if they were going to upgrade to 7 I think it would have been brought up somewhere... it would be nice to see more info on what there is planned for Central.

Third thing:
You keep comparing Central to a browser, even though Central is not a browser.. why is that? It would be like me comparing an car to a train. Yes they do reasonably the same thing but.... That's not it. I'm talking about other standalone flash players. EXE's that you can make with Screenweaver, or Flash Studio Pro. The integration with the native operating system is much higher than Central I think. (though I'm not sure about Mac, but it's not a big issue as there are so few out there, it is a risk that is justifiable). You say Central has more integration with the OS, more than what? Are you comparing with the browser again? I didn't say it was spyware, but I do not want to have to explain that it isn't (in fact I don't even know if it is or not, there's a problem right there). You say that running a windows OS is more risky than Central, so? What type of comparison is that? I don't have to justify the OS, it is already on there, and it's been researched already. The risks, vulnerabilities have already been figured out, and the companies behind these OS's have proven that they will support them. Even if it was less or more secure, how do I prove that? How do I go in with irreprovable proof that it is secure?

I don't understand where you are going with the toolbar favorites thingy.. that's what the OS's programs list is for. Can you put a shortcut on your desktop to open up a certain central app right away? Or do I have to open it up and then click on the app I want..?

Fourth thing:
I said above but I'm going to say it again, if I was concerned with how the browser worked I would have compared it myself. The idea is that my app looks distinct compared to the other apps up. I mentioned that in my post.

Fifth thing:
I don't undestand what UX means. Again you are referring to the browser. What do you mean that the browser is short for RIA's? Your answer doesn't answer my question on WHY I NEED to install Central. Why do I NEED to use Central to deploy my apps. What does it have that I can justifiably say to my bosses and colleagues "We need this, we need to put money into developing apps for this NEW platform"

Sixth thing:
Very interesting point. I like it. We use a central type system at work to deploy apps to all the computers at work, and when there is an update or new app that needs to be installed, it just gets configured in a text file and the next time the user logs in, it gets updated or installed. An ingenious method, cheap, and does not require manpower to make it work.

Seventh thing:
That's not an answer. I'd be chewed up and spit out all over the department for providing an answer like that. Let me help you understand where I am coming from. Central is not verifiably stable. Nor secure. Nor has it been around for long. Do applications have to be around for a while to be trusted? yes. Why? because we have other alternatives. Central must prove itself that it will be here. It must prove that it is worth the risk, money and time that is required to study, test, and deploy applications to it. Telling me that other apps may also go off the market is not reassurance in any way whatsoever.

Eighth thing:
If a large company needed a stateful client, they would never ever go for Central. In essence it is freeware. It's free to develop for. There are no guarantees anywhere (that I have seen) that MM's framework will ALWAYS work. If they needed a stateful client, they would spend thousands and thousands of dollars and develop something. Small companies might go to Central, but again, they will first try establish the risk factor. Which is in essence what I am trying to do.

I mean no insult to you, but I don't think you read my post properly and instead interpreted it as you wanted. You made a lot of assumptions in your answers and answered all my questions and none at the same time. I know you are a huge fan of Central, and as a fan I would hope that you would be able to meet my questions head on with proper and real world answers. I know nothing of your past, or your experiences and can make no assumptions, but I feel that you have never really sat in a meeting with the execs, architecture and infrastructure managers and had to explain why you *need* to use a certain software. What it does, why, how, where and with who, for how long, which type... blah blah blah.. I think you undestand where I'm leading. :)

I know that you may come back to me with questions on this one (what about other software?), but it isn't for Central to question me, it is for me to question Central. I see your type of answers all over the place. Mike Chambers does the same thing (sorry Mike... but you do, maybe not all the time but...). It is not for you to question me about why I am asking these questions. Nor is it your place to make comparisons to other software (well, they do this and that so... kind of idea). It is about taking these real life worries and risks and meeting them face to face giving options or reasons why something is so and what can and will be done about the remainding.

Posted by: Graeme at February 8, 2004 12:45 AM

Graeme,

Thanks for the comments, questions, concerns. One thing to keep in mind is that the currently release of Central is a developers version, and its goal is to get Developers familiar with the APIs and concepts behind Central.

This does, not make any of your concerns less valid, but I think it will help to put some of my answers in context:

>#1 : English only

Yes. That is the case. Our focus has been to make the platform solid and full featured, and then to begin to localize it into other languages. That is still the track we are taking.

>#2 Flash 6

Well, that is just a matter of timing, we began working on Central way before we began working on FP 7. We determined that instead of redoing a lot of the work, we would release it based on FP 6, and then update it to FP 7 soon there after.

The next version of Central will be based on FP 7. Future releases after that should be aligned very closely with new Flash Player versions.

>#3 Third Thing : Not confident you could sell an app

I am not sure what you are comparing this to (I don't know how you normally deploy apps), but:

> I don't want or need the extra work that is required to justify why I have to use another company's framework, design/application to hold my application

This threw me off a little since the Flash player, a browser, etc... are all another company's frameworks, design , applications.

>A lot of clients do NOT want to install anything that is not secure, and Central is definitely high on that list.

You bring up this question of security a couple of times. I am not sure if there is something specific to Central that you are concerned about, or rather it is just a matter of being suspicious (and rightfully so) of any new executable on the desktop.

But, fundamentaly, if you are not confident, you are not confident. I suspect what would change that is having some of your other concerns addressed.

>#4 Branding

Yes. We have been doing a lot of research and customer calls lately, and this is something that has been coming up.

Expect this to be addressed in coming releases.

>#5 our plans for Central

Yes. This is primarily due to the fact that this is a developer's released, focused on developers. However, I think you can get a glimpse of some of our ideas / plans for distribution when you look at our partnerships with companies like Intel, Yahoo and AOL.

>#6 pricing

fyi, it is 20%, not 25%.

#7> server technology

I am not sure what you mean here. I think that you are referring to the fact that Central is installed from Macromedia? Is that correct?

That is a legitimate concern, but of course is not just an issue with the Central player. (i.e. the Flash player is also installed from Macromedia).

Again though, it is a legitimate concern, and all I can say right now is that it wouldn't be in our interest to cut our developers off at the knees, by taking away a player that they relied on.

In the longer term, we are looking at more fundamental steps to alleviate these concerns.

#8>not wanting to install another app.

I don't necessarily agree with you here. I think if the application is useful, then users will consider it. If the installation is relatively seamless (as it is with Central), then I think it makes it more likely that users will install it.

However, this will ultimately be driven by the usefulness of the applications created.

You mentioned security issues again. Is there something in particular you are concerned about? How could we allay these concerns? What type of information would you like to see?

>but it's cool only to the developers right now,

Yes. I agree with you on this. This is the primary goal of Central right now. As far as:

>extreme amount of tutorials, white sheets, and now wallpaper blog entries

we are just trying to get information (technical and general) out about Central to developers. I think this is the first time that it has even been insinuated that we are getting too much info out... :)

Anyways, hope that helps. I think you bring up some very legitimate and valid concerns. This is not the first time we have heard them, which among other things means, we are in a pretty good position to address them in the future.

mike chambers

mesh@macromedia.com

Posted by: mike chambers at February 8, 2004 02:57 AM

Good stuff, thanks for bringing it up... critiques are valuable.

But it's long, particularly with quote/counterquote comments, so I'll selectively pick ideas.... ;-)

Localization: Yes, this is a big issue. There was some discussion of it previously somewhere, but the complexitiy is that there are FOUR levels of location: the Central shell itself; any individual tool within it; any datasources that tool calls (TVGuide, weather, etc); then if you're in commercial distribution there's the Exchange and (more importantly) the transaction service which is government-dependent. This has got to be solved, but for 1.0 there are other issues first.

Not sure I understand the core concern behind "but it's flash 6"... this thing has been in development for a long time, and even now we're just approaching majority consumer viewership of SWF7. Requiring an FP7? Having dual-feature sets? Not sure of the actual goal, and its ecological effeccts, sorry.

The Central model and assets *are* different from in-browser and standalone use, agreed. A new channel increases your choice, but doing good in-browser or standalone stuff in a new channel instead, just because it's a new channel, doesn't make sense. Find the best fit for a particular project.

For marketing info, I agree, it would be good to get more stuff public more quickly. But it's hard to get a group within one company to publicly commit to stuff in advance, and it's much harder when those announcements are multi-company deals. I agree with your desire here... just noting that multi-party stuff is harder.

Just some context here, if that's of help... if you see stuff you'd like different, then by all means please continue to make the case, thanks!

jd/mm

Posted by: John Dowdell at February 8, 2004 03:21 AM

Everyone has pretty much covered my points, so I don't wish to repeat. I've posted my thoughts on centralmx.com for those you want to take a look anyway:

http://www.centralmx.com/archives/000374.html

Cheers,
David

Posted by: David Bisset at February 8, 2004 04:14 AM

I got my cardboard tube the other day too. I'm intrigued but it's a big investment to learn a whole new technology. I've been kind of hanging back waiting to see what can be done with it, or what WILL be done with it. For me, all the hype in the world doesn't outdo the fact that there are still only seven apps in the app finder, none of which are remotely "killers".

I know that with all the hype, there must be developers making apps out there. I see a few novelty ones here and there on people's sites, but don't have time to scour the web looking for them.

I know that if there were at least a few dozen apps in there, and at least one of them made me say "wow!", I'd be on the bandwagon tomorrow.

Posted by: Keith Peters at February 8, 2004 04:43 AM

I had more time to write now, so please my notes here:

http://www.actionscripthero.com/blog/archives/000279.php

Posted by: aSH at February 8, 2004 06:28 AM

Synchronous!!!!

How about that! Graeme and I chose exactly the same day to jump off the Central bandwagon.

My activities to date can be found at http://e2easy.com/Central

It was good while it lasted :)

For me, Central was vindication that the ideas I'd been working on for a long time prior to Central were pertinent, despite constant critisism from my peers. (or rather graphic designers who considered that making anything other than eye-candy in flash went against the laws of nature).

A year before anyone saw Central, I demonstrated something called 'Core', written in Flash, it had a filing system, and ran several useful applications: sending ecards, making a website, publishing an e-newsletter, constructing multimedia, drawing, 3D etc.

This was a demonstrator. I wrote a paper outlining the benefits of a commercial successor to this, selling applications online etc. I started a forum to discuss this. But the world wasn't ready for these ideas.

When Central came along, I was about to complete my suite of eBusiness applications. I launched straight into porting them to Central.

Was this too good to be true!? I could write this stuff, and Macromedia would take care of the distribution!

Yes, it was indeed too good to be true.

Ok, here is my own list as to why I've jumped off the Central bandwagon. In order of importance (1=most important).

1. It's in American. This is my prime reason. I'm a British national living in Australia, and I'm excluded from selling my applications on Central. The Americans want the whole cake for themselves.

2. What does Central do that I can't do through the browser? Unplugged use is great! A wonderful innovation. I can see browser makers adopting this. But I write applications that are not bloated, suitable from thin-client use. I'm interested mostly in applications that create and manipulate internet content - so they tend to be used 'online' anyway. My Central applications invoke the browser to display instructions pages and upload .jpgs etc., anyway.

3. It's buggy. myloadvars.send() for example. Ok, this was a developers release, but too many bugs are getting through Alpha/internal testing.

4. One of my main frustrations in porting stuff from Flash to Central was the relative urls vs absolute urls issue. Relative urls are good. They enable you to develop your applications, loaded resources, shared libraries etc., within your local filing system, on your local server, and deploy your application online without going through and changing links.

Absolute uls are a pain. They cause sandbox violations in the development environment, and mean that your applications isn't portable. How hard would it have been for Macromedia to incorporate a 'base' parameter in the product.xml file, or base all relative urls from the downloaded url. (which is in fact retained by _url in Central anyway).

5. The performance of Central discouraged me. It was sluggish. Even dragging the window on the desktop was sluggish. Switching applications was sometimes slower than accessing a web-based application through the browser. With the caching in Central, I couldn't understand why this should be so.

6. It's Macromedia. Ok, over the years I've spent a fortune on their software. At one time they ranked as one of my favorite software companies. I was excited by "What the web can be". Oh! how you've fallen from grace. As a one-time self-formed Macromedia evangelist, I find myself being very intolerant of their shortcomings now.

Poorly implemented and buggy software. I use an Apple Macintosh. Using Macromedia's applications within Apple's environment highlight the differences in culture between these two companies. Apple's attention to quality ensure that it's the little things that enhance your productivity. With Macromedia, it's the little things that hold you back.

Ok, Macromedia have become the VHS-format of the internet. They have achieved this through marketing rather than by technological flair. With Macromedia changing, and the arena changing, will Macromedia hold onto their position? For me, Macromedia don't instill confidence anymore.

7. I don't like the security questions when my application accesses my server. It even asks when data is received but not sent to the server. Pop-up boxes like this may confuse the user. My browser based flash applications never did this.

8. I was always unclear about Macromedia's marketing strategy. Who exactly Central was aimed and branded for? Whether there would be alliances with embedded internet devices on fridges, TV-set top etc? Then there was a lot of talk about Macromedia pushing Central for adoption within large organisations. My own target group is the mass market of home users and small/home businesses.

Ok, so where to now?

What is the biggest single, most powerful potential advantage of Central? Is isn't online/offline use. The best thing about Central was that is was a centralised hub for all sorts of applications. A one-stop shop for consumers. Macromedia have failed to tap into a valuable resource. The wealth of flash applications out there on the internet. It is economically advantageous for the owners of these applications to have their applications listed 'centrally'. But Central put too much emphasis on being a 'new technology', lots of new objects and methods, tons of documentation. So porting an existing application to Central becomes a hurdle.

How about an Web-based alternative to Central?

Wouldn't it be great if you could just join by providing the application URL and a few other parameters of an existing browser-based application. Or, if you want to use the filing system, or share data with other applications, you could just incorporate and use open-source shared library.

Wouldn't it be great if the the standard was more open. If you could sell your applications, whatever your nationality and language, with no commission to anyone (except Paypal perhaps), if Linux users were included, and there was also the scope for including applications written in director/shockwave, quicktime, java applets, javascript, whatever.

Based on the browser, all this would be so easy to achieve. The various bits of 'glue' technology required aren't the issue - getting the 'buy-in' from a few developers to get the ball rolling, and then growing the 'consortium' is the challenge. I'm advocating a standard that belongs to the developers themselves.

I've tried this before, but perhaps now Central has shown us the way - the time is right?

Anyone Interested?

Posted by: Daniel Freeman at February 8, 2004 11:15 AM

Keith, I feel you.. this is exactly what I'm thinking. But I'm assuming it's because it's still in developer mode...whatever that means ;)

Daniel, are you trying to say that a Central app cannot be sold outside of USA? That would suck...

You have some very interesting issues there, I hope somebody from the Central team puts in some words on them. Thanks for your input, much more food for thought.

Posted by: Graeme at February 8, 2004 04:04 PM

As far as I know, the application can be sold anywhere, but the money can only go to someone in the USA :)

Posted by: Daniel Freeman at February 8, 2004 06:07 PM

Whoa - you are right - the try/buy system is US-only:
http://www.macromedia.com/software/central/license/license_programs/

The only other options for non US-developers is either the bulk package or give it away for free. What is that? I have to spend $400 before I can start selling? I guess that kills the idea for small-scale developers.

Does anyone remember the old Compuserve days? There you could also sell your own software via their framework and I think it was something like a 25% share for them. But it did not matter in which country you were located.

Posted by: Mario Klingemann at February 8, 2004 09:06 PM

I'm a Java Developer that is learning/investigation Flash/Central as an alternative to Swing/Applets/JSP (HTML Forms) solutions.

One thing I'm not too keen on is the fact that Central uses the Flash Player but is shipped with different components from Flash Pro 2k4 and those components can only run in the Central environment.

Be nice if whatever u developed for the Flash Player in a browser can be deployed easily to a Central environment (with enhance features).

Similarly with Flex, I hope the next version of Flash Professional gives u the option to design ur UIs in MXML. Being an outsider I find that Macromedias product line which produces flash content e.g Flex, Flash Pro 2K and Central seem a little fragmented, e.g all essentially uses the same Flash Player but how you develop for is quite different.

Would have liked to see some intranet options for Central as well for internal business applications.

I think Microsofts new vector based "Avalon" ui technology is quite attractive - the ability to run your applications in their new browser or offline as desktop applications with little or no code changes and are easy to install.

Posted by: xyte at February 9, 2004 04:58 AM

For the transaction service, it does currently require a US bank account and tax code, and this obviously needs to be expanded in the future. I wish these FAQ items said more about the current "why", myself:
http://help.yahoo.com/help/us/payments/

The tricky thing in this area is that there are multiple demands to reconcile:
-- what Macromedia can do (uh, we'd like to do it all, ASAP.... ;-)
-- what this new Yahoo! Payments system can do (ditto, I believe)
-- what the local participating banks can do (not intractable)
-- what the tax codes permit (good lord, I'm glad I'm not the one who has to read their documents and reconcile them.... ;-)

This initial step does have a transaction mechanism which goes through US banks and tax codes, and to get effective worldwide presence this will have to be generalized... I think everyone agrees here, true...?

jd/mm

Posted by: John Dowdell at February 9, 2004 06:41 AM

Hi aSH
> >>Fifht thing
> Central is currently in it's v.1... "Why would I as a
> consumer need or want to install Central?" well,
> because the browser is short for RIA's and the UX with
> Central makes the difference

really is it ? so what about all the "Flash RIA in a browser" thinggy ? Are RIAs a Central matter only ? or is it a general concept Flash can deal with ?

Posted by: Robert at February 9, 2004 11:57 AM

All the concerns you have are concerns of central develoeprs in general. My experience so far says that MM is looking into all these issues. They are not being unnoticed and will be addressed in the next release or versions afterward. Now to talk about the benefits...

Posted by: Dominick at February 10, 2004 12:04 AM

JD, thanks for the comments. I wanted to get back to this after I had heard from Mike, so here goes. Replying to both at once here.

I fully understand how hard localization can be, it's tough not being able to get a timetable of when it will be implemented but it's good to hear it's in the works.

Linux over PDA's.. good idea. For the time it'll probably be a lot easier. I don't actually own a PDA yet (waiting for something better... performance, memory, batteries.. flash support so I can use it with flashcom)

Memory hits, yes this is big I would assume. Judging on the amount of "areas" that you have to cover it could be tough, combining this with the fact you have to rely on the developers.. I think Central will get blamed for a poorly developed app. I would assume there would be some kind of screening test done by MM?

I have a question about AOL though, does it cost money to use? To "tap into"? Or does it come with the dev of Central? Sounds like something I would want to move into but how will this effect FCS I wonder.

And a last question about payment services. If Yahoo doesn't meet your expectations of providing international service, will you use another service in conjunction of Yahoo? or maybe move to another service altogether to accomodate the non-american developers out there? or will you stick with them and only provide for americans?

I will expect to hear more over the coming weeks about MX2004. You said it!! I hope I don't have to open another contest or something ;)

Last note on this, Mike you have been quite responsive and have answered a lot of my questions and I'm quite grateful that you took the time out to do so. I do have some more thoughts but I'm going to organize them a little better before I post. Most likely build an app first before I go posting about something that I have no experience in.

Thanks again.
Graeme

Posted by: Graeme at February 10, 2004 02:20 PM

>I have a question about AOL though, does it cost money to use?

We haven't announced all of the details around the AOL Presence API. However, at the MAX conference last November, AOL emphasized that their primary goal is to make the barrier to entry low. They really want to tap into the creativeness of the Flash community, and see what they can do with their network.

>payment providers

We are actively working to expand payment services support outside of the US. This is a very big priority for us, but is a lot more difficult than it seems it should be. This is due mostly to figuring out all of the tax issues and implications specific to each country.

mike chambers

mesh@macromedia.com

Posted by: mike chambers at February 11, 2004 05:25 AM

xyte is more than right.

I'm a flash dev, but I use also JAVA/C#
and the big difference with flash is that ALL is fragmented in our development process

per example: AS2 and JSAPI in MX2004
they are both based on ECMAscript
but they are very differents
ok perharps they don't want to achieve the same goals

and now we compare all:
AS1 / AS2 / JSAPI / components v1 / components v2 / central API / FCS API / central halo components / flex / etc....

this is clearly fragmented, not unified
I'm meaning by that, that for each new MM app/concept developpers have to learn new way of doing things

where is the RE-USE ?

it's become like the browser-javascript-difference-hell at nescape4 vs IE4 times

FMX worked a way
FCS work that other way
MX2004 is again another way
FLEX work another way also
...

I don't want to be harsh but with C# for example
the way of working wiht it wether it was in beta1, that I write something in notepad and use CLI compiler or the full featured VS studio, or free C# editor with SDK v1.0 or v1.1 or others update
or even with the mono port
the way of working C# doesn't change, it's unified,
the things I learned somewhere can be re-used elsewhere, and as a developper this is VALUABLE.
(I could have made the same assertion with JAVA)

with flash I got the impression that you have to spend more time learning new way of making things work (and a hell lot of hacks to simply make things works, thanks to an active community)
than to actually spend time to programming.

this is not even rants this is just a sad statement.

yeah I feel fragmented ;)

Posted by: zwetan at February 12, 2004 01:03 AM