The SDK is not responsible for resolving namespaces ( FX namespace )

[Brian Holmes]

The white paper reasoning behind the FX namespace can be found here:
http://opensource.adobe.com/wiki/display/flexsdk/Gumbo+Component+Architecture
in the Interoperability between Halo and Gumbo section.

In essence the FX namespace is used to avoid ambiguity and collisions
with Halo components to allow interopability between the two
libraries.

This has the makings of an ongoing problem with the SDK, not just for
Gumbo but for future versions of the flex sdk. When flex 5 comes out
are we going to have a GX namespace? It's imperative that a reasonable
middle ground be found for backward compatibility and future
implementations. I'm certain Matt C and the gang know this. Because of
the way we can interchange and intermix mxml and action script, flex
has a unique migration problem when moving the language forward.

The utilization of the FX on class names incorrectly assumes the flex
sdk should be responsible for resolving namespace issues, when in fact
it should be the developer who decides which library they should
import. The flex sdk should only look for collisions and point them
out to the developer, and it does this already.

In action script this might mean having to use fully qualified
namespaces, which would be a pain, but that's the point of
namespaces. But in mxml, the ns import should be easily taken care of.
Having a <fx:Button /> and a <mx:Button /> right next to each other is
acceptable in my opinion. Or going forward we could have <mx3:button /
> and <mx4:button /> perhaps? The only real time this is an issue is
for developers maintaining older source code that want to use new
functionality. As long as gumbo supports the functionality in the halo
components, there isn't much reason why a developer would build a new
application in gumbo and utilize halo components. ( I could be
mistaken, but I can't imagine myself doing this, currently ).

I think we should create a few pages on this group that reside as
"living documents" that mirror and reference the gumbo specifications
that we can use to present our concerns to Adobe and the flex
community.

Thoughts? Ideas? I may be way off on this issue but that's how I feel
about FX.
Brian..

[Tom Chiverton]

2009/2/1 Brian Holmes <brian.j...@gmail.com>:

> This has the makings of an ongoing problem with the SDK, not just for
> Gumbo but for future versions of the flex sdk. When flex 5 comes out
> are we going to have a GX namespace? It's imperative that a reasonable

Exactly. In a years time, should I use Button, FxButton, GjButton, ...
? It has the makings of a big problem.

> namespaces. But in mxml, the ns import should be easily taken care of.
> Having a <fx:Button /> and a <mx:Button /> right next to each other is
> acceptable in my opinion. Or going forward we could have <mx3:button /
>> and <mx4:button /> perhaps? The only real time this is an issue is

Exactly.
And your CSS can refer to the fully qualified name too, if you
want/need to apply something different to the two classes.

> for developers maintaining older source code that want to use new
> functionality. As long as gumbo supports the functionality in the halo

And in that case, use the Flex 3 compiler :-)
I see no reason why you should be able to feed unmodified Flex 3
source to the Flex 4 compiler, and expect to get the same output from
both. Maybe the Flex 4 compiler even throws a wobbly and I have to
change something. If I don't have time or inclination, use the Flex 3
compiler - it's not like it's going away :-)

> components, there isn't much reason why a developer would build a new
> application in gumbo and utilize halo components. ( I could be
> mistaken, but I can't imagine myself doing this, currently ).

The only case I can think of is if you have a 3rd party .swc library
(no source), compiled for Flex 3, and want to use it's components in
your Flex 4 application.
Even in that case

> I think we should create a few pages on this group that reside as
> "living documents" that mirror and reference the gumbo specifications
> that we can use to present our concerns to Adobe and the flex
> community.

An idea, certainly, but lets double-check the straw poll via this
thread - I think most of us think that FxButton should be renamed to
plain Button, and the name space used to tell which Button class or
CSS to apply, right ?

--
Tom

[Ben Clinkinbeard]

Based on what I've seen so far, I don't think Adobe is even considering implementing CSS namespaces because its not doable in their release timeframe. My guess is that regardless of what the SDK team might say or do, their bosses have declared a release window (Q4 2009 I think) and they have to hit it, no matter what. That being said, I think our only hope is convincing them that requiring the use of class selectors via styleName is an acceptable burden to place on developers who are mixing components. Personally I think that would be fine.

The other thing I wonder about is whether or not CSS ambiguity is really even a problem. You can make up any style name you want and throw it into a CSS definition without problem. If the component doesn't support that style it simply fails silently. Taking that into account it seems like the only real problem would be if a developer wanted to use type selectors for both versions of Button, but that developer would surely be an idiot and deserves to have their code broken anyways, right? :)


Ben

[Brian Holmes]

- I think most of us think that FxButton should be renamed to
plain Button, and the name space used to tell which Button class or
CSS to apply, right ?

I agree with this Tom. The developer is responsible for namespace
resolutions.


On Feb 2, 5:53 am, Tom Chiverton <tom.chiver...@gmail.com> wrote:
> 2009/2/1 Brian Holmes <brian.josep...@gmail.com>:

[Tom Chiverton]

2009/2/2 Ben Clinkinbeard <ben.clin...@gmail.com>:

> Based on what I've seen so far, I don't think Adobe is even considering
> implementing CSS namespaces because its not doable in their release

Fair enough...

> timeframe. My guess is that regardless of what the SDK team might say or do,
> their bosses have declared a release window (Q4 2009 I think) and they have
> to hit it, no matter what. That being said, I think our only hope is

That would be a real shame, but it's not unusual really. Cutting
features to meet deadline is normal.

> convincing them that requiring the use of class selectors via styleName is
> an acceptable burden to place on developers who are mixing components.
> Personally I think that would be fine.

Me too, actually, from my "it's OK to force developers to change code
if they change compiler major version" statement, this follows.
This would apply even if the component was a binary only .swc of course.

--
Tom

[Tom Chiverton]

2009/2/2 Tom Chiverton <tom.ch...@gmail.com>:

> Me too, actually, from my "it's OK to force developers to change code
> if they change compiler major version" statement, this follows.
> This would apply even if the component was a binary only .swc of course.

https://bugs.adobe.com/jira/browse/SDK-17854 would appear to be the
5th most voted bug in the database.

Can we get that number up from 60 to 119, which would make it the most voted ?

Maybe we should each post one blog entry, but not all on the same day ?

--
Tom

[Simeon Bateman]

Speaking from experience they can rename the classes with no ill-
effect.

I am actually managing a fork of the sdk where I have fixed the class
naming and manifest files, and I continue to merge the teams updates
and changes into my codebase.

I agree with Ben that "whether or not CSS ambiguity is really even a
problem" because I consider it not to be. With all the ways we have to
access an element via css including the new stuff in flex 4 this is
not really even a consideration.

But I dropped my full thoughts on this on the bug comments in jira:
http://bugs.adobe.com/jira/browse/SDK-17854#action_227169

So I wont bore those who have already read this there.

Thanks,
sim

[Adam Flater]

Wow... thanks for sending those.. I love Deepa, but doesn't that post sound a little bit like "We're not sure if Flex Developers can really handle namespaces." ??? Obviously, Adobe is still figuring out how to make this Flex thing a money maker. So, catering features to senior developer's who are likely not switching away is not nessecarily in their best interest. They need new devs and more businesses using Flex. The justification here seems more about accessibility for new Flex developers, and not the best pragmatic solution. Honestly, if that's the case, I'm inclined to cut them some salck on that one. I'd like Flex to have more success as well be the best tool for RIA dev, but these two things are not always complementary.

[Doug McCune]

I agree with Ben that "whether or not CSS ambiguity is really even a
problem" because I consider it not to be. With all the ways we have to
access an element via css including the new stuff in flex 4 this is
not really even a consideration.

I think the CSS stuff is going to be a dealbreaker. Even if in all practicality it turns out that developers will typically never run into a problem where they want to style both the halo Button and the gumbo Button controls both using a class-level Button selector. This is a justification that comes up over and over, and as someone mentioned, the argument to add namespaces to CSS simply isn't viable due to timeline restrictions or higher level architectural decisions that won't be changed. So I think the argument presented to Adobe needs to address the CSS issue, and the answer needs to be better than "it doesn't matter." Because if that's the solution we give, even if all the other issues have beautifully acceptable solutions, I think they'll still just be able to say "but it doesn't work with CSS" and the argument is lost all over again.

I could totally be wrong on this, and it might turn out that conflicting class-level CSS selectors simply isn't a big dfeal, but I've heard it come up from someone at Adobe in pretty much every discussion about this topic. I'd suggest that we don't just blow it off as unimportant (even if that means not "solving" it in any way but at least presenting well thought out and very detailed explanation of what might remain problematic and why those problematic choices are preferable to the prefix).

Doug

[Simeon Bateman]

I tell you man, I thought separating the language namespace from the
component libraries was genius. I was pissed when they took that way.
I think teaching the proper use of namespaces is so much easier than
trying explain the magic that is the manifest files.

Even for new developers the prefix is only confusing because the mx
prefix is convoluted. Some classes have AS implementations, some
don't. The real push to remove the prefix is to be inline with xaml.
which I think is the worst idea ever. I have actually heard someone
from adobe say "xaml doesnt need prefixes why do we" and i just about
choked him.

But again, I am a bit over zealous about this stuff.

sim

On Feb 2, 8:42 am, Adam Flater <adamfla...@gmail.com> wrote:
> Wow... thanks for sending those.. I love Deepa, but doesn't that post sound
> a little bit like "We're not sure if Flex Developers can really handle
> namespaces." ??? Obviously, Adobe is still figuring out how to make this
> Flex thing a money maker. So, catering features to senior developer's who
> are likely not switching away is not nessecarily in their best interest.
> They need new devs and more businesses using Flex. The justification here
> seems more about accessibility for new Flex developers, and not the best
> pragmatic solution. Honestly, if that's the case, I'm inclined to cut them
> some salck on that one. I'd like Flex to have more success as well be the
> best tool for RIA dev, but these two things are not always complementary.
>

> On Mon, Feb 2, 2009 at 7:59 AM, Tom Chiverton <tom.chiver...@gmail.com>wrote:
>
>
>
> > 2009/2/2 Tom Chiverton <tom.chiver...@gmail.com>:

> > > Me too, actually, from my "it's OK to force developers to change code
> > > if they change compiler major version" statement, this follows.
> > > This would apply even if the component was a binary only .swc of course.
>

> >https://bugs.adobe.com/jira/browse/SDK-17854would appear to be the

[Ben Clinkinbeard]

I would encourage everyone to read Simeon's JIRA comment linked above. I think with a small bit of compacting and cleaning it up it would make a perfect candidate for our "Fx manifesto" :)

The best thing about it is that it puts no onus on the tools, because I think that is a surefire losing battle.

To Adam's point of accessibility, I agree with Simeon that the namespace approach is actually easier to learn.

[Simeon Bateman]

I agree that they "think" the css issue is a big deal. But its only a
big deal to them because they have to figure out how to wire the tools
to support it.

From a developer stand point it *is* a non-issue.

sim

[Doug McCune]

Right, and after reading your comment in JIRA maybe that kind of argument is enough. I guess my point was just that if the CSS thing is cast aside as a non-issue in whatever recommendation is presented to Adobe, then it gives them an easy out to fall back on. I'd suggest even throwing together some examples that show that using the same selctor for both halo and gumbo components that share names would be fine and do what you mostly expected it to do, and then that any additional styling requirements would not be a burden since adding custom stylenames is so easy (yeah, this is stupid to have to show a concrete example of, but I think this point has to be drilled home for it to be a non-issue with Adobe).

Doug

[Adam Flater]

Good points guys... yeah the namespace is probably less confusing from a novice perspective... and as an experienced trainer I trust Simeon's take on this regarding what new devs may be inclined to pick up quicker. It comes down to this, the collision problem that needs to be solved is really best solved using a namespace. That's why they were invented in the first place.

[Simeon Bateman]

I have the code you request, but its running against my fork because
of course thats where the name changes are fixed. So I can give code
and a sample swf thats already compiled if we want to go that route.

sim

On Feb 2, 9:02 am, Doug McCune <d...@dougmccune.com> wrote:
> Right, and after reading your comment in JIRA maybe that kind of argument is
> enough. I guess my point was just that if the CSS thing is cast aside as a
> non-issue in whatever recommendation is presented to Adobe, then it gives
> them an easy out to fall back on. I'd suggest even throwing together some
> examples that show that using the same selctor for both halo and gumbo
> components that share names would be fine and do what you mostly expected it
> to do, and then that any additional styling requirements would not be a
> burden since adding custom stylenames is so easy (yeah, this is stupid to
> have to show a concrete example of, but I think this point has to be drilled
> home for it to be a non-issue with Adobe).
>
> Doug
>

[Ben Clinkinbeard]

I am creating a separate thread for each of Deepa's points because I think Doug is right. We need to specifically and thoroughly address each of them.

[Tom Chiverton]

2009/2/2 Simeon Bateman <simba...@gmail.com>:

> I am actually managing a fork of the sdk where I have fixed the class
> naming and manifest files, and I continue to merge the teams updates
> and changes into my codebase.

Hold on.
Are you saying you have a fork of Flex, without the FX prefix (but
with both Button classes), that is getting all the other updates from
trunk ?

--
Tom

[Simeon Bateman]

Yeah Tom,

That is exactly what I am saying. A few weeks ago I took the Adobe
Flex SDK and "fixed" it. And every couple days since then I merge the
new changes from adobe's code into it.

The code I posted yesterday is current to the revision number in the
file name (mid day yesterday). There have been less than 10 new
commits to the flex 4 stuff since then.

Flex builder is not the most cooperative, but if you seperate your
mxml and as in different files then everything goes pretty well.

But yes, I have an up to date non borked copy of the sdk.

Thanks,
simeon

ps. this is not done on Adobe's servers and the code has not been
publicized to the world at large. I use git because its better at
merging code changes.

On Feb 3, 1:47 am, Tom Chiverton <tom.chiver...@gmail.com> wrote:
> 2009/2/2 Simeon Bateman <simbate...@gmail.com>:

[Tom Chiverton]

2009/2/3 Simeon Bateman <simba...@gmail.com>:

> But yes, I have an up to date non borked copy of the sdk.

Maybe we should think about showing the world this - that way we can
clearly show how code for Flex3-on-4, Flex4-on-4 and
Flex3-and-Flex4-on-4 would differ between our vision and Adobe's.
And we can prove *it works fine* more to the point...

--
Tom

[Simeon Bateman]

Well now you have hit the head of my problem. And its one I have been
trying to solve since about October.

I know lots of us follow the commit logs or the rss of the changes
from the forum. I have been doing this for a long time. So I saw
when they made this switch for the Fx names back in october. I have
read all the wiki docs and have been watching them work on the gumbo
component set as they go. So I knew right off the bat this was
silly. So I started talking to people about it. And everyone I
talked to but 1 person thought this was a bad idea. So they chased me
higher up the tree. I went higher and higher till one day I met Dave
Story the new VP responsible for the products we love. After talking
to people about this I realized that the problem was not one that was
a technical challenge. This is one of those decisions that I think
happened in response to the politics inside adobe. And while the
people who understand the reason why this is a bad idea dont have the
power to change it. It was at this point that I realized that our
"open source" sdk was in really bad spot. And that management would
not change this without a business need. There needs to be an
alternative to the Flex SDK that is open to community input so that
Adobe has competition and has a "business" need to change its ways.

So I started looking at how mxml can be used as a language separate
from the components that are implemented in the halo and gumbo. Using
the flex 4 sdk I can use mxml to layout an application and have it
compile a swf for me. I built a really simple container framework and
used Keith Peters minimalcomps components and tested that I could
actually build a simple application. Compiled it was 40K. Instead of
450.

But I didnt really want to write a framework on my own, so i played at
removing the dependencies of openflux on UIComponent. This sent me
down a day long rabbit hole of nastiness. So I talked to ben about it
and he started working on it a little later. Turns out this was on
the road map for him anyway. But since that is a really large
undertaking I started looking at other solutions. I started looking
for open source AS frameworks and found open pyro. It only took a
couple modifications to their code to get it so it could be used from
mxml. But while they have put a lot of work into the framework I am
not sure its "right" for community consumption.

So after all this I realized that I really do like what Adobe is doing
with Gumbo. I realized that what I really want is a Gumbo build that
is not messed up. So checked out the code and started doing search
and replace. It took a half a day the first time, but I got it so I
could build an application using all the niceness of Gumbo without the
yucky names. It only takes me a little bit each day to integrate
their changes into my work so I keep it up to date.

The real problem is that while flex is really an xml language the flex
builder mxml parser is really dumb. So if you use the existing Flex
Builder but dont put a prefix on the namespace it wont give you code
completion. So the real problem with adoption of something like this
is tooling.

Not to mention that I am still not convinced that releasing a fork of
the flex framework is something I want to do at all. At first forking
flex seemed like the right idea. But I decided to try to rally some
community support and push them into fixing things first. That keyed
off a couple ranty blog posts that the community picked up on, and
well now we all now how that turned out. We got adobes attention, had
a meeting, realized they had no intention of fixing this on their own,
and then we made this group :)

So the real question, is has anyone else tested that sdk of Ply I
posted? And is releasing it to the community a good idea?

Thanks,
sim

On Feb 5, 4:55 am, Tom Chiverton <tom.chiver...@gmail.com> wrote:
> 2009/2/3 Simeon Bateman <simbate...@gmail.com>:

[Brian Holmes]

Sim,

Showing the community that the Fx prefix can be technically removed
is a start. However, If there was a competing sdk supported by the
community, the problem is still as you said the Tooling. A community
driven sdk would not be enough of a modifier to change Adobe's
business need; only a mass exodus of flex developers from Flex Builder
would do that, so a community driven sdk would have to provide an
alternative plugin for eclipse. Even more, the sdk and plugin would
have to prove themselves over time for it to make it possible to sell
the community implementation to companies purchasing flex products
developers make, ie apps people build or training, etc.. The long and
short of any community sdk and plugin would have to take the current
implicit backing of Adobe out of the picture for us to accomplish our
current goal of removing the Fx prefix and keeping the SDK under
constant development by Adobe, and if succesful it would still leave
the community with a competing sdk and plugin mess. Digression at it's
finest.

Adobe needs to make money off the sdk and they're trying to find that
in the tools. Perhaps they shouldn't have called the sdk OpenSource,
but rather OpenCode, because that's what it really is.

Coming back again to our goal of removing the Fx prefix. I'm becoming
more and more convinced that for this to happen, we need to make some
big splashes in the community while still being respectful for what
Adobe has done. Lots and lots of PR and lots of flex developers on our
side. Some of the ideas I've had are:

- Having a well written Declaration of Fx Defiance that clearly
tackles the reasons for with the community reasons against and also
shows developers how to get involved with changing the prefix such as
links to the bug forum to vote, blog posts such as Deepa's so people
can leave comments, people to email, such as Dave's etc. We can create
a Page on this site that does this.
- A youtube channel where devs can publish videos for their reasons
why they don't want the prefix. ( Doug will have to add an explicit
language warning ;-) )
- A weekly occuring -1 for Fx day that we all Twitter and Re-Twitter
that publically spreads a link to the aforementioned Declaration of Fx
Defiance
- A weekly occuring -1 for Fx blog day where we get as many flex devs
to blog about the not wanting Fx. It'd be neat to see AXNA with a
bunch of posts arguing against Fx.
- A -1 for Fx facebook/LinkedIn group that we can all join and
encourage other flex developers to join.

If we can make a big splash without being openly hostile and news
publications and big tech blogs and twitter folk with lots of
followers start to pick it up I think we'll finally be getting
somewhere.

[Michael A. Labriola]

For what it's worth I would say it is imperative that some community
support is built and that the discussion stays in the spot light.

Either Flex is a real open source project or it is not. If the answer is
no, then I think releasing a fork is an easy decision. If the answer is
yes, then the community discussion, consideration and reaction must play
a crucial role in the planning process, not simply a secondary role to
be managed.

I know and like the people this will most likely effect, but frankly
many of the decisions as of late seem to be focused on growing the
breath of the Flex community at the expense of the depth. This creates
more problems than it solves and it makes me worry about the future of a
product in which I am extremely heavily invested.

[Brian Holmes]

Michael,

> Either Flex is a real open source project or it is not. If the answer is
> no, then I think releasing a fork is an easy decision. If the answer is
> yes, then the community discussion, consideration and reaction must play
> a crucial role in the planning process, not simply a secondary role to
> be managed.

Agreed. But I'm afraid Adobe will always say it's a real open source
project, but then
still make arbitrary decisions concerning it's future. If we do all we
can to get the Fx axed and Adobe moves forward
anyways we can at least arrive at a conclusion.. for better or worse.

[Michael A. Labriola]

Sure. I agree.

Interesting thing is it really isn't up to them. If there is a fork,
then it is really up to us to decide which one is the framework we are
behind. Mind you, I am not yet up for full mutiny, but I believe we do
need to influence this destiny. That's why I am willing to hold off
another week before I ask Doug to design me a FTF (Fork the Framework)
Tattoo.

Mike

-----Original Message-----
From: flex-sdk-commu...@googlegroups.com
[mailto:flex-sdk-commu...@googlegroups.com] On Behalf Of
Brian Holmes
Sent: Thursday, February 05, 2009 12:10 PM
To: Flex SDK Community Committee
Subject: Re: The SDK is not responsible for resolving namespaces ( FX
namespace )

[Brian Holmes]

Let's start with an Axe Fx tattoo to begin with?

[Juan Sanchez]

http://share.scalenine.com/images/fork.jpg

[Tom Chiverton]

2009/2/5 Brian Holmes <brian.j...@gmail.com>:

> big splashes in the community while still being respectful for what

Yup, we need to do this.

> - A weekly occuring -1 for Fx day that we all Twitter and Re-Twitter
> that publically spreads a link to the aforementioned Declaration of Fx
> Defiance

And yup again.

And I'd really like to be able to link to a FxButton-free version of
the SDK from each one...

--
Tom

[Ben Stucki]

wow, the duality I'm reading into this is pretty much awesome.

[Simeon Bateman]

I think the problem between Brian and Mike's views is that Mike is
focusing on the bigger picture. The Fx problem is a symptom of a real
issue, and that is the lack of influence and planning the community
has on the sdk. Fixing Fx is like covering a rash, it doesnt make the
problem go away it just keeps people from knowing you have an STD :)
Until the next outbreak that is.

Getting them to fix the Fx problem lets them cover up the rash, and
makes us feel like we have input, but it has not changed the real
problem. And thats what I am here to deal with. The can change Fx
and continue to develop the rest of the SDK behind closed doors.
Until the make another big mistep and we get all riled up and cause
them to cover the next rash.

Ok, anyhow. I am still not ready to fork the framework. But if thats
the solution that causes them to get treated for their metaphorical
STD then the time will come for such an action. The real truth is I
am not sure we want to fork the SDK, I think we may want to start
working on flex 5 now.

On Feb 5, 10:18 am, Brian Holmes <brian.josep...@gmail.com> wrote:
> Let's start with an Axe Fx tattoo to begin with?
>
> On Thu, Feb 5, 2009 at 11:12 AM, Michael A. Labriola
>

[Brian Holmes]

> The Fx problem is a symptom of a real
> issue, and that is the lack of influence and planning the community
> has on the sdk.

So what we really lack is a process that clearly defines goals for
when the community can trump Adobe. The bug database was their attempt
at this. Perhaps someone with contacts can ask them to clarify?

[Ben Stucki]

I think that's exactly right. In my mind the bigger picture is why this group was formed. Obviously we're focused a lot on the Fx prefix right now because it was a miss-step on Adobe's part, but it absolutely represents a flaw in the framework planning process somewhere - and that's even more distressing. Long term I'd like to find a way for us to help keep things like this from happening in the first place. We can only give feedback on what Adobe is discussing publicly, but if it's vital feedback then I would hope it's not hard for Adobe to find the value in that.

[Michael A. Labriola]

Well, gotta keep it interesting.

 

Guess my point is as follows. I am up for doing anything that will get the real core issues penicillin... damn sim and his metaphors.

 

If it becomes clear at some point that the real core issues just can't be fixed, then I am up for helping on a new open source project design to create a next generation framework for rich internet applications. If that project happens to be based on a fork of any existing frameworks, then great. If it is a brand new entity, then I am up for that too. I just know that I am frightened with where the product line (not just the framework) seems to be going and that worries me.

 

Mike

 

P.S. Thanks Juan, but I am still giving it a week before I make a fork tramp stamp out of it.

[Brian Holmes]

> I am up for doing anything that will get the real core issues penicillin

Agreed.

> If it becomes clear at some point that the real core issues just can't be fixed, then I am up for helping on a new open source project design to create a next generation framework for rich internet applications. If > that project happens to be based on a fork of any existing frameworks, then great. If it is a brand new entity, then I am up for that too.

Agreed.

Does anyone want to propose a first draft on a course of action that
we'll take to enable ourselves?

[Ben Clinkinbeard]

Call my cynical but I really don't see Adobe ever giving up control of the SDK. It will never be a true open source project in the sense that community has the final say. Final say will always rest with Adobe because without it they can't plan and design long term tooling solutions. I am actually OK with this because I think there is a happy medium, which is this group (or a similar one) serving as a real buffer/go-between/ambassador between Adobe and the larger community. An actual community steering committee if you will, where we would get earlier and greater access to Adobe's plans and got to provide real feedback. I think allowing the general community to steer the SDK is a bad idea for several reasons (*ducks shoes thrown by Sim and others*) but think Adobe steering it by themselves is bad as well.

Can't we all just get along?

+1 for really stepping up how vocal and organized we are in protesting Fx. Yes, its only a rash, but I think if we can show Adobe that we can either aggravate or sooth those rashes they are more likely to make the choice of using as to help their cause.

[Tom Chiverton]

2009/2/5 Simeon Bateman <simba...@gmail.com>:

> am not sure we want to fork the SDK, I think we may want to start

Think of it as a demonstration that it's perfectly possible to use two
Button classes at once, technically, and what the implications for the
areas Adobe are worried about would be.

--
Tom

[Tom Chiverton]

2009/2/5 Brian Holmes <brian.j...@gmail.com>:

> Does anyone want to propose a first draft on a course of action that
> we'll take to enable ourselves?

FxFriday ?
Mass Twit and Blog postings ?

Before we do that, we should agree the public purpose of this group
(see other thread). Ben probably wants the final call on this and
that.

--
Tom

[Doug McCune]

I just want to point out that in my view up until now the fact that Adobe has closely controlled the Flex SDK has been a godsend. The success of Flex has relied on the ability for Flash Player and the Flex SDK to progress quickly. Thank god there was nothing stopping them from ditching Flex 1.5 completely and starting fresh with Flex 2. If we had had a steering committe that got in the way back then, I'd worry about how much progress would have been made. So I think it's worth pointing out that if we think Adobe is making the right decisions, nobody has a problem with them controlling the SDK, and that it can be invaluable in terms of moving the SDK forward quickly.

That said, Adobe also makes some bad decisions, the Fx prefix being one of the more recent ones, but I could point to numerous other decisions that I think were wrong,  like the outsourcing of Flex 3 components to their India team without regulating code quality. I guess my point here is that I want to avoid the misconception that all will be grand if Adobe listens to everyone before they move forward. I think the agility of Adobe to change the SDK (the radical shift from 1.5 to 2, and now the radical shift from 3 to the Gumbo architecture) has been extremely important to the product as a whole. When it comes to frameworks like this, staying one step ahead of the competition is imperative. Otherwise we'd all be writing HTML apps. I want to make sure we don't give up agility for the "right way" to run an open soure project.

I worry that we bitch about the process when there are specifics we don't like, but don't acknowledge the benefits of the process, so we end up sounding like whining children who want to have their cake and eat it too.

Doug

[Simeon Bateman]

I'll save my thoughts on how I think the project should be run for a
post i am puttin on justins thread.

But if I thought forking flex would be the solution I would not have
held off on posting my fork. That being said I think we really do
need to get vocal and allow people to show their support.

As such I propose that its time for us to come out of the closet with
our group. And I think we all need to make a post about our
intentions to support and guide the community. However to guide the
community or to show adobe the community supports us I think we need a
way to show numbers. Bens survey was great for getting that started
but I think the http://flexsdk.uservoice.com website will be a great
resource for that. We can have the comunity show its active support
and allow them to make suggestions through that site.

What do you guys think about that? I think that it does require that
we follow Brian and toms advice and come up with some official mission
statement.

sim

[Ben Clinkinbeard]

I completely agree. This is exactly what I meant when I said I don't want the general community to steer the SDK. I just want a small group, preferably this one, to have input on the direction. As Brian said moments ago over IM, there just needs to be a clearly defined process for us to provide input. If there is criteria and we fail to meet it then so be it, but right now there is no definition of what our power is and the proper way to wield it.

[Adam Flater]

I agree as well. Making our intent known will give us some clout to be
taken seriously. One concern... how do we clean this group focused and
on point? (Aka avoid a Flex Coders scenario). We want to be large
enough to have an important voice, but small enough to be productive.
I'm not sure I have a good answer for this. As soon as we make this
announcement everyone and their mom that'd written a line of Flex code
is going to want to be on the list. Frankly, that would put me out, I
couldn't keep up with that chatter.

Ideas? Thoughts?

[Simeon Bateman]

At this point I dont think we tell them about this list, or at least
we make it clear that the archives are for transparency.

This problem is why I recomment the use of the uservoice site. It
allows for a clear disucssion and voting from the community. From
which we can take the info we want if we choose. But I think that the
uservoice site is a great tool to faciliate the conversation with the
community at large.

sim

[Brian Holmes]

Would we have to pay for uservoice?

[Simeon Bateman]

Not until we have 5000 members. http://uservoice.com/signup

That was why I set up the account at http://flexsdk.uservoice.com

sim

[Tom Chiverton]

2009/2/5 Adam Flater <adamf...@gmail.com>:

> on point? (Aka avoid a Flex Coders scenario). We want to be large
> enough to have an important voice, but small enough to be productive.

I think just having the names we name, all signed at the bottom of
each statement, is going to be just as effective as having lots of
people do.

I don't often blow my own trumpet in public, but, damn, we have some
of the finest minds and personalities of the Flex community here.
Hell, even lowly me has managed to qualify for a free book from Adobe
:-)

The problem becomes one of how we actually stand between the thousands
on blogs, twitter, FlexCoders etc., and Adobe.
I say we give this uservoice thing a go. It can't be worse than a
200-user free for all :-)

--
Tom

[Adam Flater]

It might also be helpful to put a cap on the # of people in this
group. Then, if people migration out we could nominate others in.
That seems a little formal, but enforcing some standard on the growth
will directly effect the productiveness... (in my opinion)

[Ben Clinkinbeard]

I think we are at about 20 right now which seems like a reasonable number to me. Some have not participated at all though so maybe we/I should ask them to confirm a desire to participate.

Ben

[Adam Flater]

Agreed.

[Tom Chiverton]

2009/2/5 Ben Clinkinbeard <ben.clin...@gmail.com>:

> me. Some have not participated at all though so maybe we/I should ask them
> to confirm a desire to participate.

Agreed.
We can't expect people who, for whatever reason, don't speak here, to
agree to put their name to statements.

Some sort of artificial ceiling on numbers does sound harsh, but it
limits the length of time a given topic can run for well, and means we
shouldn't drown under 'me too' invites.

--
Tom

[Adam Flater]

Yeah.. that was might point.. a limit sounds harsh, but a reasonable
cap might also be an easier way for us to facilitate productive
participation. Instead of a limit we could nominate people into the
group based on their participation in the user voice forum.

[Ben Clinkinbeard]

I will check with those who have not yet spoken up. If I don't get a response by Monday or so I will go ahead and remove them.

As for new members, I think for now we should stick to a "by nomination only" method. So if any existing member wants to nominate another person they can, otherwise the group will stay as it is. I think we all understand adding members should be done prudently.

I will assume everyone is OK with both of these points unless I hear otherwise.

Thanks,
Ben

[Michael A. Labriola]

Sorry to back up on this thread a bit, but I just got back to my machine.

 

I agree completely that a certain agility has come from Adobe holding tight control of the product. I also agree it has gotten us this far, but I fear problems as it matures. Mainly because:

 

#1) Adobe writes frameworks, not applications or derivative frameworks.

Frankly most of the people working on these designs are doing it from a purely theoretical anticipation of what developer might need. At least in my experience, that doesn't work. For some reason I am stuck in metaphor land today, but .. they may steer the ship but if they don't pay attention to the weather report from the community Flex might not exist.

 

#2) There is an inherent conflict of interest.

Adobe must sell builder and suite licenses to stay in business. That, at least to me, necessarily means they are going to make decisions based on the products that are making them money, not necessarily in the best interests of the framework. One could argue they are correlated but I think the very reason this group currently exists is that conflict.

 

#3) Staying ahead of the competition also means making sure developers want to work with your product

If Adobe releases and evolves the framework way ahead of any competitors but does it in a way that drives away their early adopters, then they lose regardless of the features. Granted my projects are sometimes stupid-big and are likely outside of the intended use cases. Perhaps I am the only one but does anyone else feel like FP10 perhaps isn't as stable as it needs to be? That working with flex builder is sometimes a nightmare? I just worry that the efforts to stay ahead, especially with Flex, may well erode what I like about the product.

 

I hope the dialog remains open with Adobe. I would love this to be a product I can always be behind, but I do often think that forking it and presenting an alternate view of the world may be the only way to ensure both agility and the features I want.

[Brian Holmes]

Personally I think that using their own bug database voting system
against adobe would be most effective. Imagine if they got to work
tomorrow and had 500 or 1000 votes against the Fx prefix. Currently
there's 64. https://bugs.adobe.com/jira/browse/SDK-17854 It'd force
them to respond.

I propose we do a couple of things.

- As previously stated, we come up with a mission statement,
something along the lines of the statements already proposed group.

- Then use the Pages of this group to articulate specific arguments
for or against our issues. Our Pages should then call developers to
action by pointing to specific bugs that developers can vote on in the
bug database. We can use the Pages as landing pages to blog / twitter
about in our attempt to drive traffic.

I agree with Doug that we've reaped the benefits of having one entity
making the decisions. I'd like to keep the ball moving forward by
trying to play within their framework. They've publically said the top
voted bugs become priorities.

As for new members, I think we should open this group up to anybody
who wants to participate, and elevate the current members to managers,
( committee members ) which can add/edit the Pages. Yes, it creates
chatter, ( there's a Page specific feed to follow ) but that chatter
will be centered around those ubiquitous rash outbreaks. The flex
coder problem was horrendous because there were 50 developers asking
the exact same question about the exact same code. This discussion
should be centered around bugs/enhancements, I don't think it'll would
have the same volume. As always people who want to participate will
and those who don't won't. If I was a new flex developer and I wanted
to get an enhancement it'd be nice if there was a place to go where I
could post a link to a bug and potentially create a discussion that
gets elevated enough to get fixed. Making everyone feel enabled is the
key. Signing our names to a statement might get something done, but
getting 500 votes for a fix on adobe bug system will get something
done, if nothing more than a statement by Adobe saying they're not
going to fix it.

[Adam Flater]

Warning: mentioning the bug base might be productive could cause a
vein in Labriola's head to explode... or much, much worse. Be safe
Brian, good luck. ;)

[David Tucker]

> Personally I think that using their own bug database voting system
> against adobe would be most effective. Imagine if they got to work
> tomorrow and had 500 or 1000 votes against the Fx prefix. Currently
> there's 64. https://bugs.adobe.com/jira/browse/SDK-17854 It'd force
> them to respond.

This was my point as well. As a 'voting block' for the bug database,
I believe that we hold a good deal of power. I don't know that any
issue we all targeted could possibly be ignored. I have voted for the
Fx prefix issue, and I hope that everyone here has do so as well.

> - Then use the Pages of this group to articulate specific arguments
> for or against our issues. Our Pages should then call developers to
> action by pointing to specific bugs that developers can vote on in the
> bug database. We can use the Pages as landing pages to blog / twitter
> about in our attempt to drive traffic.

I also agree that this is a good idea. The pages section will allow
us to write well-defined (and well articulated) responses to the issue
that concerns us. Voting the bug database alone won't be enough. We
need to clearly define our position.

> As for new members, I think we should open this group up to anybody
> who wants to participate, and elevate the current members to managers,
> ( committee members ) which can add/edit the Pages.

I do think we need to limit membership though. Truthfully, if we open
it to anyone, no one will keep up with the message threads because
there will just be to many people putting ideas out. IMO, more
members means less involvement from each person individually.

David Tucker

This email, and any attachments thereto, is intended
only for use by the addressee(s) named herein and may
contain legally privileged and/or confidential information.
If you are not the intended recipient of this email, you
are hereby notified that any dissemination, distribution
or copying of this email, and any attachments thereto,
is strictly prohibited. If you have received this e-mail in
error, please immediately and permanently delete the
original and any copy of any email and any printout
thereof.

[Brian Holmes]

Yeah I know. ;) But it seems the fastest way to get in front of Adobe.
I'm not fond of it either.

[Brian Holmes]

> I do think we need to limit membership though. Truthfully, if we open
> it to anyone, no one will keep up with the message threads because
> there will just be to many people putting ideas out. IMO, more
> members means less involvement from each person individually.

As George W. Bush once said, this would sure be alot easier if this
were a dictatorship. How do you encourage
participation from the community at large? The Rails Activists have an
email list and encourage the community to email them directly.
Perhaps we do the same? Ask people to follow our discussion but
contact members directly to get their issues into the fold?

[Michael A. Labriola]

Like a republic of Flex...

-----Original Message-----
From: flex-sdk-commu...@googlegroups.com
[mailto:flex-sdk-commu...@googlegroups.com] On Behalf Of
Brian Holmes
Sent: Thursday, February 05, 2009 3:31 PM
To: flex-sdk-commu...@googlegroups.com
Subject: Re: The SDK is not responsible for resolving namespaces ( FX
namespace )

[David Tucker]

This goes back to the core purpose of the group - and I have a feeling
that there are differing opinions of this amongst us. Is this a true
'community group' - or a 'committee' that is designed to represent the
views of the community. I could see value in both, but I believe if
we are going to get stuff done, we need to be the latter. There is
certainly nothing wrong with soliciting input - or even allowing
community members recommend/choose people for the group - but the last
thing I want to see is a group like the group at the Flex SDK
community meeting - where someone won't stop asking 'When are we
getting Flash on the iPhone'. That is the last thing we need.

David Tucker

[Tom Gonzalez]

I follow this thread with intent interest and want to stay part of the group, but I hesitate to add to the chatter as inevitably someone else raises the point I would have raised myself and I would have just added to the thread needlessly.  But when it comes time to big decisions I definitely want to weigh in.

- Tom

Tom Gonzalez

Managing Director

BRIGHTPOINT CONSULTING, INC.

data visualization - software research and development

direct line: 760.634.7657

fax: 760.454.2258

www.brightpointinc.com 

[Tom Chiverton]

2009/2/5 Brian Holmes <brian.j...@gmail.com>:

> email list and encourage the community to email them directly.
> Perhaps we do the same? Ask people to follow our discussion but
> contact members directly to get their issues into the fold?

I'll happily set up something@aDomainIOwn and filter the flood.

--
Tom

[Brian Holmes]

> This goes back to the core purpose of the group - and I have a feeling
> that there are differing opinions of this amongst us. Is this a true
> 'community group' - or a 'committee' that is designed to represent the
> views of the community.

Whatever differences about core purpose of this group are I do believe
we all want to see flex evolve in a way that makes us more productive
in the future. I agree that a committee is capable of getting more
things done. I'm 1+ for announcing this group, keeping as it is for
now and then for starters, publishing our reasons against Fx and
stepping up how vocal we are against it. I have no reason against
using flexsdk.uservoice.com, it's just one more tool we can use to
raise awareness and filter out good ideas and developers. But I think
as David referenced, carving out a significant voter block that drives
votes in the bug database coupled with clearly defined and published
pages for or against issues would be most effective. Once we're a bit
more organized and activated, approaching Matt C about acting in a
manner similar to the Rails Activists becomes very feasible.

As a side note, I think using something like GitHub where the sdk can
be openly forked and the community pulls drive who's the top dog
development team sounds like an awesome democratic way to drive
development. If FX stays I'm up for that.

[Douglas Knudsen]

ok, into the fray as it were.  Though as passionate as we are about Flex and about the idea of open source, the term and meaning of 'open source' is a bit 'off' at times, eh?  Anyhoo, even though the SDK is open sourced this by no means grants any one of us any rights to the direction the 'trunk owner' wishes to go.  ( consider Linus, used to be really up to him in the end about the Linux kernel. ) The direction is completely up to Adobe and hey, they are a business answering to shareholders and the like.  Might sound all icky, but that's kind of the facts ma'am.  I think they are doing a really bang up job, sure bunch of little bugs here and there, what project that large is 100% bug proof?  Further I see them as struggling in new territory, fighting the likes of MS, yet letting everyone see their goods out in full display and also learning to work with a more public community.  By more public, I compare to the previous scenarios where folks were on betas and got to help shape releases, yet still not direct Adobe per se.  They do make some big mistakes though, heck 1.5 requiring a server was nasty silly in retrospect and this FX mess is a bit of one too.  Either way, they got a big team of folks dedicated to this and this makes them pretty freakin agile in the business world. 
 
What was said at the big-uncontrollable-live-twitter-in-Connect meeting was basically, vote up your issues.  Unless Adobe comes out with some other process for considering the community at large, seems that's the process they have set up for us.  We can be cheerleaders then, eh?  Get your Fx (read product symbol here) poms out.  While not as direct and invlovled as many feel is right or wrong for a open sourced project, it is the process layed out so far.  Maybe this is what the outcome of this group can accomplish, changing this process and allowing maybe a subset of this group to act as representitves of the public at large and help steer things.  A combo of these two would be good even, eh?  The open meetings the Flex team are to have seem to me to be potentially quite beneficial, if they were run a bit better.  Adobe seems to have responded to outcries thus far with these and tehey seem pretty damn interested in the public helping shape things.

Forking seems a bit off the hook at this point, but certainly anyone can do it if they want.  Seems a freakin huge undertaking though.  Good luck with that. 

Curious, anyone following the CFML advisory committee?  Is Adobe really committed to following them?

$0.0001 expended

DK

Douglas Knudsen
http://www.cubicleman.com
this is my signature, like it?

[Tom Chiverton]

2009/2/6 Douglas Knudsen <douglas...@gmail.com>:

> Curious, anyone following the CFML advisory committee?  Is Adobe really
> committed to following them?

I asked out right at Scotch last year, and they said that, yes, if the
committee told them a purposed tag/function should have a different
name, they'd rename it.

I see Flex working the same way - of course Adobe is in the driving
seat (the number of external patches is almost zero, the number of
external commiters *is* zero AFAIK) but they are listening to the
community.

--
Tom