Teoti Graphix, LLC

Here is a nice and full summary for 14 days of blogging!

Flex Charts

The current status of the Flex Charting was brought up and whether functionality and performance would improve.

CSS was a major candidate for improvement and was actually asked that CSS be made a priority for the whole Flex 4 SDK. This means add CSS properties that would allow for display adjustments and shorthand like “real” CSS.

I think users want to see the Flex CSS leave the dark ages. It was also noted again that in the spirit of Apache, roll up your sleeves and try and fix what bugs you, then submit it to the community!

It has also been noted that Adobe doesn’t have any new charting code to contribute. Maybe some specs and prototype code but that is all. Looks like it’s up to the community to see where a new charting library magically appears from.

DataGrid Performance

The performance of the DataGrid and the DataGrid itself has been the nemesis of the Flex SDK from day one, no joke. It’s no surprise that this has come up as about the 3rd request from the community to look at.

The DataGrid has a bunch of problems, it’s idea in the real world can do a lot of things. Add on top of the functionality it requires, the component will get the most abuse from jamming huge data sets into it. On top of that mess you then want to edit and draw that data in certain ways based on data state, etc.

The above boils down to a huge mess if the component is to do everything. It sounds like there are some community members that have come up with some factory implementations that might just tame the mighty DataGrid design. Let’s put it this way, if Apache Flex in the next year or so can create a DataGrid that performs better than the last two, major win for the community.

DropDownList working on Mobile

Tink had brought up a simple little fix for the DropDownList to work in mobile applications. Another community member commented that it would be nice to have this component available in mobile because the Spinner is really heavy for just displaying small data sets.

Spoon Community Call Feb 2nd

Jonathan Campos announced that there will be an open call for community members to ask questions about the direction and focus of Spoon.

At the same time Spoon will be opening up the organization to the community.

There is also a Flash/Flex User group tour starting soon as well, you can get more information here;

http://blogs.adobe.com/flex/2012/01/announcing-flex-user-group-2012-tour-north-america-dates.html

I think an interesting question that will be asked is Spoon was founded before the knowledge of the donation to Apache. How does that change the Spoon road-map concerning the Apache way of “if it didn’t happen on the list, it didn’t happen”.

How does Apache feel about an outside project like Spoon?

I’m sure this is what the Spoon community call is all about, so don’t miss it if you have the time. For now they will be posting more information up on their site;

http://spoon.as

Falcon compiler source code / Falcon architecture

Alex updated the list on the subject. It sounds like the compiler might be available in the summer in an unfinished state.

I’m going to quote Alex here as these are pretty heavy statements;

Falcon is intended to serve not only as the compiler for FB, but as the code-model service for FB’s code intelligence.

The version of FB that integrates Falcon will not be designed to use a different version of Falcon for different versions of the SDK. This is different than today, where FB uses he MXMLC from the SDK version for your project.

He goes onto note the implications;

This has some interesting implications. One is that we can’t keep rolling out new versions of Falcon without factoring in backward compatible MXML code-gen for older SDKs. Another is that, if you muck with the language, the code-intelligence in FB will break or at minimum, won’t be able to assist in those new language constructs.

For the first issue, the plan of record was to have Falcon convert MXML constructs to data structures instead of code, and modify the SDK framework to interpret those data structures. That work will likely not be fully complete at the time of donation.

So what does this all mean? It means that the yellow brick road is full of obstacle and unknowns right now. As a development community we need to focus on the Flex SDK until the tin man at least gets his heart.

JIRA

Well JIRA is definitely up now, Bertrand has now added about 7 issues and tracking features. So the ship has launched.

Please read AND follow the warning on the main page;

JIRA issues from https://bugs.adobe.com/jira will be imported later, please DO NOT create duplicate issues for those.

https://issues.apache.org/jira/browse/flex

Logo Contest

Finally, the logo contest which is at it’s end for submissions today. I created short urls with logo numbers on the web site now, so it’s a bit easier to tag entries.

As far as voting, we still have a couple days as far as I know. More on that later.

http://incubator.apache.org/flex/logo-contest.html

Conclusion

Well, this was an action packed post. As you can see the community is chiming in and starting to get their boots muddy with requests and complaints.

JIRA is your ticket to being heard but, hesitate please before you file a bug or feature request because odds are, it was filled in the Adobe JIRA and will be migrated.

Oh yeah, this is #14, two weeks in a row! I will now pat myself on the back for something I never thought I could do, 14 blog posts in a row.

Thanks for reading,
Mike

Monday was an active day of logo entries, method overloading, source code and event handling discussions.

Pretty soon we will be talking about who is tackling what and whether commits are reverted. What bugs to fix and what fat to cut out. How to implement the future and what is priority for the next couple releases to show that there is a capable community ready to take Apache Flex to the next level.

Logo Contest

This should be the final day I talk about the logo content as it winds up after a week of entries. It was really interesting to see all of the entries thus far and how much they varied.

As usual head over to the logo contest page and check out the new entries.

http://incubator.apache.org/flex/logo-contest.html

Method Overloading

The topic of method overloading came up and since there were a whole bunch of threads, I had to rewind back to where this originated from.

Don’t take my word for it but, I am pretty sure this topics beginning came from Alex talking about overloading and the new framework he has been working on(last week). From this standpoint the overloading has to do with backward compatibility to the older Flex SDK.

From there members started talking about changing the compiler to add functionality A, B and C. Debates were expressed and we arrive back at a point blank question about method overloading.

Here are three items to think about;

- descriptive names verses method overloading
- cross-version backward compatibility
- trade off between overloading vs API bloat

Source Code Commit

The source code “should” be committed today and at the very latest tomorrow. All the legal papers have been signed off by Adobe and Alex is now just waiting to get the SVN dump file from the Adobe servers to hand over the to ASF Infrastructure to dump into Apache’s SVN server.

Exciting to say the least, focusing on issues that are not related to code in a code related project has been backwards for sure but, shows that the Apache Flex community knows how to keep the fire lit until more wood arrives.

I think the fire burning for the last two weeks was purely from ideas and communications. We can now take that energy and put it into a first time release for Apache Flex.

Lightweight Event handling

The question was brought up about interest in a lightweight event model for a branch of the SDK targeted for mobile, high performance small foot print type applications.

The AS3Signals framework was mentioned as an option. There are as always two sides, one that sees the signal framework as a performance enhancement, the other that does not want things added to the core that can be included as an external library and implemented on a per application basis.

Whatever the case may be, this seems to be a recurring debate on how the Flex SDK is going to evolve and what will be included in the core. Only time will tell.

These issues do bring us back to an original thread about the modularity of the Flex framework. Whether to include all in the whole shebang or create modules that allow an application developer to include what is necessary for their own application.

JIRA

The JIRA site is up and running but it’s not clear whether the mentors are waiting for the Adobe JIRA issues to be migrated before opening up issue creation to the public.

I only say this because you can get to the create issue page but no issues have been logged.

Conclusion

These summaries are meant to peak your interest if you so chose. The next step would be hitting the mail archives and getting the full deal by reading the entire thread and sometimes surrounding threads.

Mark Mail – flex-dev

Thanks for reading,
Mike

Well it was mostly another quite Sunday except for a couple conversations about the Flash Player AVM and code quality in relation to class line size.

The Apache Flex logo contest has definitely been a popular target for a lot of logo authors sending in their ideas for the Apache Flex branding.

Dependency on Adobe

There was an interesting thread that brought up the project’s dependency on Adobe’s Virtual Machine (Flash Player). Although there have been many articles based on this very issue, and seemingly some state that this issue is dependent on the success or failure of the Apache Flex project, here are some thoughts from other community members;

- Most Java projects in Apache do not include a JavaVM which is required to run the code.
- Apache Flex will be a strong community with or without the AVM.
- Apache Flex is mainly concerned with the Apache Flex framework.

The main point of this is that a lot of the project members are not to concerned about this dependency right now. Without going into the specifics, the project members see a future that may use different strategies and deployment than the current Adobe Flex SDK provides.

If there was not a sense of future change in the Flex SDK why would so many developers being willing to put their time into something that will just stay the same and continue to be minimized by the greater development community as a Flash Player only alternative.

You can read some of my older blog posts to see that I am a supporter of this change and know that the SDK is just an abstraction. I could see things that can change and make Apache Flex something that is more of an agile platform to create different target productions.

Line size determines code quality

This can’t be the first time this has been brought up in software development right?

You have some that say any method or class larger than so many lines should be refactored or has stale code in it. You have another side saying that it’s not the size that matters but how many things the class is doing.

I know one aspect of OOP I learned was one class one responsibility. If you really think about this, this is kind of an open ended statement. Really what it’s saying is dependent on the magnifying glass you use will determine what a software architects intention of the ONE responsibility is.

In laymans terms this would be saying; on one hand a cars responsibility is to get someone from point A to point B. This is the perspective of a driver. On the other hand an engineer says a car starts, accelerates, stops, idles, plays music etc, I think you get the idea.

So depending on what perspective you use to generalize a class’s responsibilities everyone will come to a different conclusion. This is exactly why I have no opinion on this dead end debate.

The monolithic UIComponent was brought up and I do agree, the lines of code in that class creates a brittleness that only -50 degrees could do to metal. In fact, this is how I come to my conclusion, how brittle is that 1000 line class, is it maintainable?

Apache Flex logo contest

Over the weekend there was about 12 new logo entries for the Apache Flex logo contest. Check the new entries out here;

http://incubator.apache.org/flex/logo-contest.html

Designers still have today and tomorrow to get those entries in. I’m sure there will be about a 12 hour grace period for different time zones to get new entries in on January 17th.

Conclusion

Opinions are like heads, everybody has got them and the success of the Apache Flex relies on community members breaking down their own opinions and creating a cohesive whole. Only then can we move forward and tackle the problems that exist and create something in a reflection of the whole.

Thanks for reading,
Mike

Saturday on the mailing list mainly consisted of logo entries. I’m sure a lot of members are just waiting for the source code to arrive and figuring out what the next steps are to Apache Flex’s first release.

Logo Contest

The logo contest will be ending on Tuesday January 17th, so you still have a couple days to get those final entries in!

Something brought up was whether an author/designer can submit multiple logos. Originally I replied that the author should combine them on one link but, then I realized they were not talking about design “variations” but separate logo ideas.

So the answer is Yes, a designer can submit multiple logos by sending an email to flex-dev@apache.org and appending a number after the authors name like [LOGO] My Name #1, [LOGO] My Name #2 etc.

http://incubator.apache.org/flex/logo-contest.html

JIRA

The JIRA instance is up and running but I don’t think we are able to use it yet due to the fact that Alex hasn’t got the issues migrated from the Adobe JIRA. This is a great step in the forward direction though!

https://issues.apache.org/jira/browse/flex

Conclusion

As usual Saturdays go, mainly silence and rest (for some). Stayed tuned for this weeks action, we should be getting into the mechanics of issues and source code commits and fixing some bugs.

Thanks for reading,
Mike

Hi,

The Flex-Dev summaries continues. I always like doing things I thought I couldn’t do. I’m going on 10 blogs posts in a row, I have never done that before.

It’s interesting how an idea like the flex-dev summaries starts out as something and then turns into something else. I have been amazed at how many off blog conversations I have had where developers and community members have voiced their appreciation with what I am doing here as far as just trying to get information out.

The main goal of these summaries is to educate myself. I like the term “practice makes better“. Each time I write something or think about it, I am giving myself the opportunity to think about the issue in a new light.

I have also noticed through Google Analytics that the apacheflex category is being linked to and read 100′s of times. In the beginning I really didn’t think to much about the impact of that category. Until the day I actually clicked on what others are seeing. Wow, that is a rough chronology of the beginning of the Apache Flex mailing list!

For users that come to this project 6 months or a year down the line and have the ability to read a chronological summary like that, the thought gives me the motivation to keep doing it everyday for a while. Even on slow days or weekends.

After the Storm

I know this was a Friday but there was something very nice about the fact silence occurred after a huge day of voting and opinion madness. It does show that the community that is involved thus far really does have the capacity to sit back and digest conversations and disagreements without having to start the same mess again the next day. Right on!

Flex SDK Source Code

Alex has announced that the source code has passed legal! He said it should be around Monday and that Adobe will give Apache a huge dump file to dump into the folders to maintain the svn history.

This is great news for the projects momentum and I think perfect timing for the project as a whole.

Community members start your engines, if you thought the mailing list was on fire this week, wait until next week.

JIRA

Alex also stated the they are working on the JIRA migration and it will be a huge pain because of potential username conflicts. There are going to be some “gotchas” that he brought up;

- considering changing the authors of all current issues to something like “AdobeFlexSDK”
- create a field to store the original Adobe issue number
- take all current comments and concatenate them into one long comment submitted by AdobeFlexSDK
- Adobe Flex JIRA issues have lots of custom fields that I expect Apache Flex JIRA won’t have

Flex-Users Mailing list

Doug Arthur started a new thread about the flex-users mailing list (Note: in my last blog post I called this flex-user which was a mistake on my part). Seems like now that the dust cleared there may have been confusion between two threads that were being talked about when opposition was being made.

This is a very good example of Doug waiting a day and asking the question in a very detailed way to get the feedback he needs.

It looks like there are enough mediator volunteers to get the list off the ground and so far the thread has not had any real opposition to creating it now.

Flex SDK Binary Release location

The question was asked since the svn repository only stores the source code, where are the release built SWC and libraries going to be stored.

http://apache.org/dist/

Falcon compiler and MXML

A couple updates from Adobe’s Gordon Smith about the Falcon compiler.

- has a lot of support already for .mxml, .css, and .properties files as well as .as files
- compiles the MXML directly to bytecode and does not produce intermediate AS.
- it is not yet alpha quality and you wouldn’t want to use it in any projects

MadComponents

Daniel Freeman pointed out in a blog comment yesterday;

Many developers are already united around a new light-weight component set, built with touch interaction and mobile devices in mind. MadComponents

I did check this set out a while back and looked interesting. He uses XML for layout and I see a lot of Android similarities to his framework.

If you’re interested in a new take on AS only mobile component framework, go check it out!

Source Code: http://code.google.com/p/mad-components/

MadSkool Blog: http://madskool.wordpress.com/

This is what makes the ActionScript language so great, the ability to create frameworks.

Conclusion

Not much of a conclusion today, just waiting for next week when the real action happens, source code committed, JIRA up and running and the Apache Flex logo voted on.

Thanks for reading,
Mike

The Thursday edition of flex-dev@apache.org consisted of voting debacles, best practice debates and whether or not to create a flex-user mailing list.

On the plus side, an Apache Flex blog has been created and we have more logo entries for the community to check out.

Voting the Apache Way

Voting was a central force in the thread titles, I was to blame for one of them but, only going off of what our mentor Bertrand was suggesting. He suggested we needed to find out the protocol for voting on the new Apache Flex logo. I’m not going into detail on this subject since my head is completely fried in writing the words “logo contest“. For more information on this discussion, the thread shouldn’t be hard to miss.

Best Practices

This is another thread that went off the charts for number of threads posted. It has to do with whether Apache Flex should in a way dictate “how” developers should organize/pattern there development.

The consensus is, any community member is free to write drafts and propositions on what and how they think code and frameworks should be standardized. Just because you write something, doesn’t mean that the community is going to follow it. More than once the old cliche’ of “one size doesn’t fit all” was used. Using that as the back drop I’m sure you can infer what the issue is all about.

Flex-User Mailing list

This debate has been going on for a couple days and it doesn’t seem to be close to getting resolved. Pretty close to a split in my opinion. The two polar sides consist primarily in;

- Apache Flex does not have a release and doesn’t require a mailing list at this time, there are plenty of resources available for Adobe Flex right now.
- What actually defines what is discussed on a flex-user list, is it a standard community help channel.
- If the flex-user list is created now and we direct community members that may have off topic questions for the flex-dev list, it will help define the flex-user list

I think the main problem some members have against it right now is they don’t want the community to think there is actually something to support right now. From reading the threads, it doesn’t sound like most members are against it, they are against creating it before a first release.

Whatever the case may be, this is surely a candidate for something that needs a decision to stop the huge flows of email where a conclusion can definitely be reached.

Apache Flex Blog

It was requested last week and it’s here, the official Apache Flex blog with entries from the PPMC members.

The way it’s set up for now is a member can post a blog post on the mailing list and have it accepted(edited) by other members. Once it’s accepted, the blog post will be published on the blog.

Peter Elst will have the first blog post that might arrive later today. You can book mark that here;

http://blogs.apache.org/flex/

Logo Contest

The logo contest has about 12 entries after I update the site, so go on over and check out what the community is coming up with designing to new Apache Flex!

http://incubator.apache.org/flex/logo-contest.html

HaXe and compilers

There is another discussion talking about HaXe and “what if” scenarios. Not going into much detail here as we don’t even have the source code of the Falcon compiler to compare it to anything.

Pre-processors have been brought up and how they would affect compile performance. Basically, members are discussing the possibility of “Extending” the language through pre processing code for method overloading etc. As mentioned any of this talk is purely theoretical because we are talking about a compiler that doesn’t exist yet.

Conclusion

It’s hard to write summaries about things that go on for ever and have no closure. I’m sure most would agree that this is the way things are when you bring together a huge assortment of different brains from all over the world.

I would say that all in all, the first two weeks of Apache Flex have been very positive and rewarding for the community. I know we are still waiting for the code but, it’s nice these other little hiccups are getting attention from the start instead of happening with mission critical decisions such as releases.

Thanks for reading,
Mike

Yesterday was kind of a slow day in that there wasn’t much new topics. Having seen this list from the start and I can say I have read every message in the till, people are getting anxious and impatient(in a good way).

The messages of “can we focus on this instead of that and not talk about this until a release” are getting boring to me.

It’s funny how life changes though, by next Friday the energy will be the exact opposite of yesterday and there won’t be any time to be bored.

Logo contest

The logo contest now has 7 entries and 2 more I need to add this morning. The great thing about this is the community is listening and wanting to contribute. This should say something for when Apache Flex get’s it’s code and the community starts submitting patches and documentation!

Again, go check them out and get inspired, maybe you will be the one that everybody looks at as the contributor that gave Apache Flex it’s identity!

http://incubator.apache.org/flex/logo-contest.html

Coding Best Practices

There has been quite a long discussion about Application coding practices and the MVC microframeworks have been brought up as well. As some of you may know that read these summaries, I brought up Coding Conventions last week and on the list. Coding conventions don’t have to be strict, they are there so developers are looking at the same style of code to promote speed in development. What is being talked about right now is dictating Coding Standards in relation to application/component patterns.

Alex points out nicely that we are in a constrained environment and sometimes we need to cheat. An example given is having everything replaceable and using separation of concerns is fine in theory. But if that code creates a performance issue in the Flash Player, a developer should then cheat the standard a bit to get optimum performance over having a composable object just because the standard says use composition always.

I think we are getting application development mixed with framework development and they are two very different animals.

Mailing lists and Resources oh MY!

This is the one subject that is getting beat to death. To be or not to be, that is the question.

Actually the real question is does the flex-dev mailing list want the flex-user mailing list split right now. From the sounds of it, it might actually happen.

People, I think we all need to understand that the flex-dev mailing list is about the framework, pushing it forward, submitting patches and discussing commits. All channels available for the actual application development of Flex are still around and relevant.

Conclusion

Well, it was definitely a hump day on the list, one of practical concerns and repetition. Add me to the list of impatient developers that want JIRA up and the SDK committed.

Mike

Hi,

Well this was one of those days where you get the calm before the storm and then the storm. Yesterday was the storm of replies and misguided replies to irrelevant subject lines. Basically chaos on a mailing list.

This was the first day where some conversations took a personal tone. I must admit I have come a long way in my life realizing there is a difference between passion and poison on a mailing list. The later being completely disruptive and destructive to a mailing list.

The passion wouldn’t be as bad on the flex-dev list if members would create a new Subject Line.

Having read every single post yesterday of the 300 or so, I would say you will only get half of the topics discussed by looking at the mail archive subject lines. Which means most of what people were going back and forth on are buried in the sands of time. I can guarantee 75% of people are not going to read every thread in a 50 thread long conversation unless they are really bored. Not to mention the subject line only pertains to the first 15 threads out of 50.

So this begs a question; When we contribute to a 25-40 long list of threads (of the same subject line when the subject has completely changed), are we really doing it for our personal reasons or for the benefit of the community that comes after us looking through the archives?

Moral of the delema, when you sense a new storm brewing, slice and dice, make a new Subject line and don’t reply, create a new thread so it gets set back on the root.

Logo contest

The logo contest is in full swing and so far there are 5 entries on the first day.

http://incubator.apache.org/flex/logo-contest.html

IRC Channel (Apache Flex Resources)

I love this type of stuff because I think pointing out my own faults creates stronger understanding with myself. I have been quite busy committing the web site, logo contest, reading mails, responding and actually developing a little bit at the same time.

A patch was submitted on the list to add the IRC channel to the Community links on the website along with a small page describing it. Well, I automatically committed his update (which is not just a 1 – 2 step).

Pretty interesting to see how fast people respond! Basically I was using the Apache Way, lazy consensus in that I didn’t hear people say NO, so I committed. Well I am proud to say that I own the prize of the first REVERT in svn for the project.

Through my action I pulled out of the PPMC members that they don’t want the IRC attached to Apache Flex in an “official” way. Alex also noted that we don’t even have a release so there is really nothing to support yet attached to the Apache Flex name.

Resources

So the above thread then lead it’s way into where do people go for Apache Flex support?

Can I remind the community that source code is not committed and we haven’t released anything.

So the answer is the same places you have always gone, Adobe forums, Stackoverflow, Flex coders etc. Remember that you are still using Adobe Flex, not Apache Flex.

BlazeDS

The question of BlazeDS is getting some support to be brought into the Apache Flex project. Why? If there are not enough initial committers or community involvement in it’s own project, BlazeDS could just rot on the vine and die.

It’s also been pointed out that there are enterprises that still use it and some of those might be interested in contributing as well.

Spark components

The question of Spark performance came up and was answered with the fact that the Spark skinning model creates 2 DisplayObjects per component. Alex also pointed out in his opinion Adobe could have retrofitted a new skinning model in all mx components in less time.

You may be wondering about how the above fits into anything. The subject of Flash Catalyst and it’s coupling to the direction and design of the Spark framework was discussed. Unfortunately it looks like the failure of Flash Catalyst is the main reason there is still not a polarity between mx and spark component sets.

Alex also pointed out that there were other driving forces such as;

declarative graphic primitives, MXML-only skins, and tooling integration

This then begs the question of what we are to do as Apache Flex can now steer it’s own boat. Do we retro fit mx components with skinning, do we try and slice out the fat caused by FC in the Spark framework, do we settle our losses and realize there needs to be a new component model built from the ground up taking into the concerns of mobile, performance, granularity, composition, cross compiling etc.

It’s up to the community but since Apache Flex IS components, this will determine what traction Apache Flex has in the future and it’s ability to compete with existing technologies on the level of agility.

Two final notes on Spark performance as Alex put it;

Spark was living on top of UIComponent. It is hard to run fast when you put on heavy shoes.

The basic idea is that our design goals have changed significantly since Flex 3, and we should design a framework for those new goals and sacrifice some backward compatibility. Trying to carry all of our legacy forward is probably not going to make it successful.

Flex SDK commit

The question was asked again about when the source code would be committed and Alex said they are having a harder time getting it through legal so expect around the end of the week. Which was about my guesstimate last week.

Also note that it still could be next week, it’s not how fast Alex and Carol can get it done, it’s how many hoops do they have to jump through to get it done.

Conclusion

What you are seeing happening here is a bunch of elementary kids getting loud and anxious to get their little boots on the field trip bus. I mean this in the most sincere way folks, since there is no source code and JIRA yet, the group is having time to explore some of the more abstract ideas before the reality comes down and we wake up from the initial dream.

Mike

Logo Contest

The Apache Flex logo contest has begun! The contest will end on 01-17-2012.

On the 31th of December, 2011, the Apache Software Foundation has accepted the Flex SDK into incubation. Apache Flex is now a community project managed by Apache (ASF). The migration from Adobe to Apache involves a re-branding and you can contribute by proposing the new Apache Flex logo.

See the logo contest’s rules and details http://incubator.apache.org/flex/logo-contest.html

You can use the Twitter hashtags of #flexlogo or #ApacheFlex directed at @ApacheFlex as well pointing to your logo url and assets.

Whiteboard

The Apache Flex’s whiteboard area;

The whiteboard is for experimental stuff – anything that one or several committers want to work on and make visible to others.

Between the committers it has been brought up that there are two possible strategies for organizing the code that gets committed there.

One; separate all root folders into committer name like I have done with /trunk/whiteboard/mschmalle/mobile-popups.

Two; separate the root folders into functionality and then say committer name.

My opinion as a committer is that we should just use our names as the root, keep a README file in the root of our folder to allow anybody curious the ability to see what is going on at a glance.

Maybe root level directories can be voted on as a group so that only things that will have a shelf life end up at the bottom most visible folder.

I just donated a mini PopUp framework to the whiteboard yesterday, this is also why the conversation came up, seems like the Apache Way of just do it is good because it allows things to surface and get resolved.

You can see the code here; http://svn.apache.org/repos/asf/incubator/flex/whiteboard/mschmalle/mobile-popups/

SDK’s future

Quotes are from Alex Harui.

Carlos Rovira brought up some questions;

Dynamic View States

Capability to create states on the fly and let other code handle the transitions, etc. of these states.

Adobe has some work in this area that will likely get contributed.

AOP

AOP is probably a language thing, which we do not have control of. As soon
as you start bytecode manipulation, you are no longer programming in
ActionScript and prone to even more debugging and analysis issues than folks
who used to mix C and Assembly. I would first want to see why a better
composition model for features can’t do pretty much everything you’d want to
do in AOP.

Flex Core refactor (SystemManager, Managers -PopUpManager,…-)

My whiteboard folder will eventually include a completely new framework based that will be mostly backward compatible with Flex but will have smaller base-classes, a minimal DI implementation, and not use AS features that are hard to cross-compile to JS.

Maven support

It is the #1 vote on JIRA. Just need someone to start working on it.

Metada Evolution and DI frameworks support

I’m very much against the use of metadata at runtime. It is a whole other language that is not first-class in the VM and probably will never be, and currently does not have any ties to ActionScript. The kinds of DI used at the application framework level by Parsely and Swiz don’t need to be tied to the same DI in the framework and probably shouldn’t be for performance reasons. It is different to inject a large application model once vs injecting a data model for every component. Now if we find a good DI implementation for the framework layer, application frameworks may decide to borrow or extend it, and I’m pretty sure the framework DI will not be parsing metadata at runtime.

IRC Channel

Michel Boudreau commented that he runs the #flex channel on freenode.net. He was asking if community members wanted to make it the official channel for Apache Flex.

Bertrand commented that IRC is fine for water cooler talk but anything that involves decisions or direction needs to be discussed on the flex-dev@apache.org list.

Conclusion

Usually I do not directly quote Alex as much as I did above but, he gives such concise answers to questions that I could not resist on the items listed.

On the new framework that Alex is talking about, I asked him this;

Alex, can you say what your framework classes are based on? Is this something where mobile and multi-touch can be used/composed but the framework not dependent on them?

His answer;

My current thoughts are to create a framework that is very granular and uses lots of composition. I have prototypes where HelloWorld is a 28K swf.

I’ll leave you with that wonderful future vision.

Thanks for reading,
Mike

Well this was the first Sunday edition and for those who had a life were probably resting and relaxing.

This list sure didn’t, not much of major interest happened, just some followups and simple things.

Also, anything that is say controversial from an opinionated angle, I’m probably not going to bring up in these summaries. Gossip news papers and advertisements have one place in my house, on the bottom of my birds cage(home)

Apache Flex Logo Contest

The Logo re-branding contest is not yet in full swing but the DRAFT document is up on the Apache Flex website for those that want to start up their favorite graphics software and give it a swing.

UPDATED

I created a new page on the website for the contest specifically.

Check out the rules/information; http://incubator.apache.org/flex/logo-contest.html

We are asking for fresh and innovative designs here, so try to erase what you previously had branded in your head with Adobe Flex and put a new spin on the logo to symbolize the new future Apache Flex is headed.

AIR Native Extensions for Linux

A community member asked about AIR native extensions for Linux. As we all should know, Adobe discontinued development before native extensions were released.

Flex Roadmap

This subject was brought up again and the answer is found within the community. The PPMC members of Apache Flex cannot stress enough that the future of the Flex SDK and it’s off shoots rely solely on the input of the community, yes that is YOU!

JIRA is the formal process to take surveys, ask for features etc, that can then in public be voted up or down depending on popularity.

Once major features or roadmap items come into focus, discussion can then be started on the flev-dev mailing list to get a consensus direction developers want to take and then can start committing code to satisfy that direction.

Not on the list but thought provoking

A mobile AS3 framework

This item was not brought up on the list but it’s something I have thought about and what are the solutions to.

Since the Flex SDK is not “defined” by the UIComponent in the future, what is the feasibility of designing an AS3 framework from say SpriteVisualElement or lower that would allow MXML or pure AS3 implementations without the dependency of the UIComponent for mobile applications.

It’s an interesting thought and one I have come to the conclusion will need to be discussed. I have written quite a few AIR mobile applications and find myself really trying to stay away from the UIComponent. I’ve actually ended up creating a small framework using the SpriteVisualElement as base to support multi-touch.

Multi-touch

This is a very important thing to think about with mobile. The current SDK was not design to handle multi-touch. As more and more mobile applications come into existence, this is a requirement. Having done multi-touch music applications(knobs, sliders etc) in both AIR and Android I would say it is 5 times easier to make a multi-touch application in AIR than Android out of the box.

So, I hope this gets talked about, I don’t think the time is now to start a conversation on the mailing list. I hope that others see the need to get away from the one shoe fits all approach we have in the Flex SDK to date.

Conclusion

That was Sunday, lets see if some code arrives and JIRA this week!

Thanks for reading,
Mike