Re: [FlexJS] PAYG definitions and guidance, Please participate

[Alex Harui <ah...@adobe.com.INVALID>]

Hi Greg,

Thanks for writing this up.  I took a quick read.  I'll do a more careful
read next week and have more detailed comments.  One thing I wanted put up
for discussion now is the notion of "defaults".  Really, I'm trying to get
away from the notion that there is one default we have to decide on.  IMO,
that's another old way of thinking from Flex.  FlexJS is designed to
support multiple component sets.  Express will have different defaults.
MDL has different defaults.  The Basic set has a particular design goal
(feature parity with SWF) and thus will have different defaults.  There is
often no one right answer, so we build different component sets and folks
will try them and decide for themselves.

Thoughts?
-Alex

On 6/30/17, 3:29 PM, "Greg Dove" <gr...@gmail.com> wrote:

>Following on from other discussions, I have made a start on something here
>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apa
>che.org%2Fconfluence%2Fpages%2Fviewpage.action%3FpageId%3D71013028&data=02
>%7C01%7C%7C35f519d4ea87431fd80808d4c0078bc3%7Cfa7b1b5a7b34438794aed2c178de
>cee1%7C0%7C0%7C636344586020292933&sdata=aj4YiAsUQDGoW5Bf%2BQ2wyJxgqmguZ18T
>Zng2jGcWIkY%3D&reserved=0
>
>In the end this will only work if people want to do it. But I do believe
>that one way of getting everyone on the same page here (and we do have
>clear signs that not everyone is), is to, quite literally, get everyone on
>the same page :).
>
>It is currently half content, half notes. There is more to harvest from
>list discussions I think, some topics have progressed further than when I
>started trying to capture ideas, so please correct any mistakes in the
>definitions or add topics and questions that need 'resolution'/guidance.
>
>I personally would like to see some concrete guidance in the 'How does
>PAYG
>get implemented' section. There were definitely the beginnings of some
>healthy discussions around some of the options for beads for example.
>(DRY,
>inheritance, utility functions etc).
>
>The goal here is to turn any list discussions around
>uncertainties/misunderstandings into something that represents consensus.
>I
>think this should be do-able by simple discussions about specific topics,
>maybe with informal voting if necessary. If there is no consensus then I
>guess PMC could do a formal vote? (I don't know what makes sense here)
>
>Beyond work on the SDK, this type of information (in some form) might also
>be helpful as part of the documentation for 1.0 when we get there, so it
>could save someone time later on as well as being useful in the near term
>(I hope).

Re: [FlexJS] PAYG definitions and guidance, Please participate

[Harbs <ha...@gmail.com>]

I think Alex was talking about default components.

MDL is a pretty good example. An MDL app has a certain look and feel. All the necessary functionality is built into the component set by default.

The point is that there are different classes of applications. Each class of applications should have its own set of components which have their own defaults. Some ideas (not necessarily realistic):

1. Skin swappable need to have their skinning changeable at runtime.
2. Widget heavy
3. Visualization apps.
4. Animation heavy apps.
5. Performance sensitive apps

Until FlexJS starts being used for real, we’re not going to know exactly how the component sets need to be structured. MDL is designed for a specific app that’s (sort of) well defined. Express is an attempt at a “general” app requirement, but who knows if it’s really the right default for a specific class of apps.

So basically, if I’m building a “foo” app, I’d pick the “foo” widget set as the starting point and that gets me pretty fart along to where I need to be. For this to be realistic, the Basic set needs to be as modular as possible. Hence PAYG and extremely modular bead architecture is critical. The thing to keep in mind is that Basic is not a default for anything by design. It’s a collection of “smallest useful functionality” that can be put together like lego. And that’s really the point of PAYG.

This is a really critical piece and I think some folks are not quite getting this and that’s creating confusion about the goals and benefit of PAYG. It’s not like we’re doing a bad job with Basic, so we have Express to fix that. Basic is the goal of the framework and Express is just one way of many possible ways of using it.

I don’t think I got it either when I started with FlexJS. I thought Alex was being extreme with his use of PAYG and splitting up of beads. However, I went along with it, and with time, I see the wisdom of this approach.

Thanks,
Harbs

> On Jul 2, 2017, at 4:44 PM, yishayw <yi...@hotmail.com> wrote:
> 
> Alex Harui-2 wrote
>> One thing I wanted put up
>> for discussion now is the notion of "defaults".  Really, I'm trying to get
>> away from the notion that there is one default we have to decide on.  IMO,
>> that's another old way of thinking from Flex.  FlexJS is designed to
>> support multiple component sets.  Express will have different defaults.
>> MDL has different defaults.  The Basic set has a particular design goal
>> (feature parity with SWF) and thus will have different defaults.  There is
>> often no one right answer, so we build different component sets and folks
>> will try them and decide for themselves.
>> 
>> Thoughts?
>> -Alex
> 
> Probably needs to be in a separate thread, but I'm not sure what you're
> asking. Default beads? Default attribute values? My intuition is that the
> default value matches the most common use case. Hence, UIBase is by default
> visible.
> 
> 
> 
> 
> --
> View this message in context: http://apache-flex-development.2333347.n4.nabble.com/FlexJS-PAYG-definitions-and-guidance-Please-participate-tp62738p62759.html
> Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [FlexJS] PAYG definitions and guidance, Please participate

[yishayw <yi...@hotmail.com>]

Alex Harui-2 wrote
> One thing I wanted put up
> for discussion now is the notion of "defaults".  Really, I'm trying to get
> away from the notion that there is one default we have to decide on.  IMO,
> that's another old way of thinking from Flex.  FlexJS is designed to
> support multiple component sets.  Express will have different defaults.
> MDL has different defaults.  The Basic set has a particular design goal
> (feature parity with SWF) and thus will have different defaults.  There is
> often no one right answer, so we build different component sets and folks
> will try them and decide for themselves.
> 
> Thoughts?
> -Alex

Probably needs to be in a separate thread, but I'm not sure what you're
asking. Default beads? Default attribute values? My intuition is that the
default value matches the most common use case. Hence, UIBase is by default
visible.




--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/FlexJS-PAYG-definitions-and-guidance-Please-participate-tp62738p62759.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [FlexJS] PAYG definitions and guidance, Please participate

[Harbs <ha...@gmail.com>]

Great start.

I just made some additions and changes. Hopefully I helped make it clearer and not the other way around… ;-)

I just want to say, that while PAYG is hard both from a framework development perspective and from an application development perspective, I firmly believe that strict adherence to the concepts are worthwhile. I say this after using FlexJS full time on both sides of the equation for more than a year.

We DEFINITELY want to make it easier for application developers to get started, and hopefully the Express set is a step in the right direction. We also DESPERATELY need better documentation and guides. Unfortunately most of us are not great writers. :-(

Harbs

> On Jul 2, 2017, at 1:40 AM, Greg Dove <gr...@gmail.com> wrote:
> 
> Thanks Alex,
> 
> I look forward to your feedback. It would be great to see  (from you or
> anyone else) -  within this thread - suggested improvements/corrections or
> other topics that should be added, or questions that should be addressed.
> 
> I know there are areas that need improvement in a number of areas of the
> document, but I'm hoping that this will be 'fixed' by making it a shared
> goal and getting input from others, not by me kludging away in the
> background. I wanted to get something up that is a starting point only.
> 
> I do understand the avoidance of the 'swiss army knife' approach to base
> classes in Flex 4, but had wondered about whether we were focusing on the
> 19% of functionality that might be useful for 5% of developers (Basic) vs.
> the 20% of that will suit 80% of developers (e.g. express) -I'm not saying
> that the pareto relationships there are correct, just using it for
> 'relative' comparison. But I think it is just a case of getting used to a
> new way to thinking, which is different to Flex4 (and Flex3). It would be
> really great if you can lead a thread specifically about this.
> 
> I also suspect there will be no 'one true way' to make incremental
> functionality beads either. But documenting the pros and cons of each
> approach (which we already started in one of the other threads) might
> provide useful guidance about when to choose which approach (inheritance
> and/or utility functions etc). I'm looking forward to that discussion
> because I think I was getting a lot out of the earlier discussion on that
> already.
> 
> In the end writing these things in a document is not something I call fun.
> "I'd much rather be coding". But I do believe that having 'team-sourced'
> content, as an output of focused list discussions, could make the
> generation of the document content a much easier process, and that the
> process itself could help  improve decision quality, build consensus, and
> provide resources that will be useful for team alignment and future
> reference info for others. I think any one of those reasons is enough for
> me to stop trying to create more of the content myself!
> 
> 
> 
> On Sun, Jul 2, 2017 at 3:57 AM, Alex Harui <ah...@adobe.com.invalid> wrote:
> 
>> Hi Greg,
>> 
>> Thanks for writing this up.  I took a quick read.  I'll do a more careful
>> read next week and have more detailed comments.  One thing I wanted put up
>> for discussion now is the notion of "defaults".  Really, I'm trying to get
>> away from the notion that there is one default we have to decide on.  IMO,
>> that's another old way of thinking from Flex.  FlexJS is designed to
>> support multiple component sets.  Express will have different defaults.
>> MDL has different defaults.  The Basic set has a particular design goal
>> (feature parity with SWF) and thus will have different defaults.  There is
>> often no one right answer, so we build different component sets and folks
>> will try them and decide for themselves.
>> 
>> Thoughts?
>> -Alex
>> 
>> On 6/30/17, 3:29 PM, "Greg Dove" <gr...@gmail.com> wrote:
>> 
>>> Following on from other discussions, I have made a start on something here
>>> https://na01.safelinks.protection.outlook.com/?url=
>> https%3A%2F%2Fcwiki.apa
>>> che.org%2Fconfluence%2Fpages%2Fviewpage.action%3FpageId%
>> 3D71013028&data=02
>>> %7C01%7C%7C35f519d4ea87431fd80808d4c0078bc3%
>> 7Cfa7b1b5a7b34438794aed2c178de
>>> cee1%7C0%7C0%7C636344586020292933&sdata=aj4YiAsUQDGoW5Bf%
>> 2BQ2wyJxgqmguZ18T
>>> Zng2jGcWIkY%3D&reserved=0
>>> 
>>> In the end this will only work if people want to do it. But I do believe
>>> that one way of getting everyone on the same page here (and we do have
>>> clear signs that not everyone is), is to, quite literally, get everyone on
>>> the same page :).
>>> 
>>> It is currently half content, half notes. There is more to harvest from
>>> list discussions I think, some topics have progressed further than when I
>>> started trying to capture ideas, so please correct any mistakes in the
>>> definitions or add topics and questions that need 'resolution'/guidance.
>>> 
>>> I personally would like to see some concrete guidance in the 'How does
>>> PAYG
>>> get implemented' section. There were definitely the beginnings of some
>>> healthy discussions around some of the options for beads for example.
>>> (DRY,
>>> inheritance, utility functions etc).
>>> 
>>> The goal here is to turn any list discussions around
>>> uncertainties/misunderstandings into something that represents consensus.
>>> I
>>> think this should be do-able by simple discussions about specific topics,
>>> maybe with informal voting if necessary. If there is no consensus then I
>>> guess PMC could do a formal vote? (I don't know what makes sense here)
>>> 
>>> Beyond work on the SDK, this type of information (in some form) might also
>>> be helpful as part of the documentation for 1.0 when we get there, so it
>>> could save someone time later on as well as being useful in the near term
>>> (I hope).
>> 
>> 

Re: [FlexJS] PAYG definitions and guidance, Please participate

[Justin Mclean <ju...@classsoftware.com>]

Hi,

> You could be right that folks are just too used to the old Flex way of
> thinking.  If you've never hit the performance and size issues I've seen
> then maybe you can't understand the motivation behind it, but that might
> mean the active committers are self-selected.

I’ve worked on many large enterprise Flex systems and while we run into performance issues from time to time but they were generally solvable. Sometimes in the code itself or at worse by monkey patching the SDK. Not everyone experience is going to be the same.

> it could be that the big enterprises that have been
> burned by old Flex's size and performance are no longer active Flex
> customers.

There are a large number of reasons for that i.e a lot of big enterprises like paid support from a supplier, some are still reluctant to using open source (although that is changing) and finding Flex developers these days is hard and/or expensive, other frameworks may have more traction, popularity, hype or larger communities behind them.

> Documentation is always a good thing, but as I've said several times, this
> is bleeding-edge development.

Having worked on a number of bleeding-edge systems IMO I’m not sure it really qualifies for the term. There are other frameworks in this space, other cross compilers etc etc and there’s nothing really that cutting edge about it. It’s true that it’s currently mostly untested in production so in that way it may qualify.

>  I'm just not sure we are ready to start paving roads and putting up street signs.

If we want to attract other developers / committers it may be a good idea to at least leave some notes on the direction travelled and how to get there.

>   Adobe can pull me off at any time.

All the more reason IMO to have some documentation and censuses around concepts like PAYG. Bus factor is a concern here. [1]

>  My managers would much rather that I help one or two customers migrate their code than
> write documents so 100 folks can migrate on their own because we still
> have enough bugs and missing features that the 100 would have little
> chance of being successful

Those's 100 people would get help from the mailing list and would hopefully become committers themselves. I think you may be thinking that Flex needs more full time people sponsored by a corporation working on it. That would be nice but also don’t discount part time committers working on it as well as there’s room for both.

>  And having a successful customer improves the chances that Adobe will continue to pay me to work on FlexJS.

What do you (or Adobe) define as successful here? We're currently working on an application what does it need to do to help that?

Thanks,
Justin

1. https://en.wikipedia.org/wiki/Bus_factor

Re: [FlexJS] PAYG definitions and guidance, Please participate

[Harbs <ha...@gmail.com>]

I agree with this.

If I had to pick the single-most difficult thing when migrating from Flex to FlexJS, it would be layout.

The new layout beads are definitely improved over the older ones, but layout is not always necessarily as intuitive or performant as it might be.

On the one hand, we don’t have constrained layout like we used to have in classic Flex. Being able to pin elements to specific locations relative to their containers and have it move/resize automatically by just specifying top,bottom,left and right values as well as percentages was REALLY convenient. To do that properly, we would need a more robust layout cycle than we currently have which brings along the overhead inherent with that.

On the other hand, even the basic CSS based layout we have probably has too much reliance in DOM to be as performant as it otherwise might be.

I imagine that we will ultimately have layout beads which go in both directions relative to what we currently have: Leaner beads which are more performant, and more robust beads which have more ease of layout.

Harbs

> On Jul 2, 2017, at 9:44 AM, Alex Harui <ah...@adobe.com.INVALID> wrote:
> 
> Documentation is always a good thing, but as I've said several times, this
> is bleeding-edge development.  I'm just not sure we are ready to start
> paving roads and putting up street signs.  In Flex 0.8.0, we overhauled
> the Layout subsystem and there are still things I don't like about it.
> I'll bet there is one more overhaul coming up.  I'm also pretty sure that
> layout gets called too often but I won't know how to optimize until Harbs
> or others get to the "last mile" and really start focusing on performance.

Re: [FlexJS] PAYG definitions and guidance, Please participate

[Alex Harui <ah...@adobe.com.INVALID>]

Hi Greg,

You could be right that folks are just too used to the old Flex way of
thinking.  If you've never hit the performance and size issues I've seen
then maybe you can't understand the motivation behind it, but that might
mean the active committers are self-selected.  I don't think we have
representatives from big enterprise app development teams amongst our
active committers and it could be that the big enterprises that have been
burned by old Flex's size and performance are no longer active Flex
customers.  Beads and PAYG is my solution to the problems I saw during the
Adobe Flex days so if we do get interest in FlexJS from big enterprises,
we have a better chance of turning them into customers and committers and
that will have much more impact on the Flex ecosystem than those of us who
are currently writing code for FlexJS.

And, it is also just good computer science.  Abstraction, separation of
concerns, composition, are all good design principles.  The regular Flex
SDK violated a lot of those principles for historic reasons.  AS2 object
creation was slow so it encouraged you to write big monolithic classes,
then when AS3 came out, we didn't have time or want to take the risk to do
a rewrite, nor were we sure what AS3's performance characteristics would
be.

I'm not sure it is right to think of this under the lens of the 80/20
(pareto) rule.  Express is supposed to be a pre-packaging of code in
Basic.  In theory, there should be no new beads in the Express source
folder.  It should only composite or aggregate beads from Basic.  And
thus, if 80% of developers use Express, 80% of developers are using code
in Basic.  And the important thing is, if someone needs to shave size or
improve performance, that someone can switch back from Express to Basic,
and start tossing beads they don't need.

I remember a survey done by Lotus 123 Spreadsheet folks back in the 90's.
At that time Lotus 123 shipped something like 100 @functions (like @Sum,
@Average).  The survey showed that something like 90% of folks only used 5
@functions.  90% of those folks use @Sum, but no other @function was used
by more than 5% of the users.  But every @function was being used by
somebody.  It was probably ok for a spreadsheet to be bundled with lots of
@functions, but it isn't good when a framework makes you include 95
functions in your app that you aren't going to use.

We have focused on Basic so far in order to prove that we can create
useful, small and performant examples and hopefully soon, useful small and
performant applications by compositing small pieces.  It may be that we
can focus more on Express going forward.  And there might be other "sweet
spots" in between Express and Basic as well and yet another component set
will arise.  We won't know until more customers actual try to migrate
real-world applications and put them into production.

Documentation is always a good thing, but as I've said several times, this
is bleeding-edge development.  I'm just not sure we are ready to start
paving roads and putting up street signs.  In Flex 0.8.0, we overhauled
the Layout subsystem and there are still things I don't like about it.
I'll bet there is one more overhaul coming up.  I'm also pretty sure that
layout gets called too often but I won't know how to optimize until Harbs
or others get to the "last mile" and really start focusing on performance.

I go back and forth between thinking we are ready to stop writing code and
start writing doc and thinking that we just need a few more folks who know
how to work on the bleeding edge to push forward at a fast pace and let
those who may be better at paving roads form the second wave that follows
after us.  Having those of us who are writing the most code slow down and
smooth out the trail behind us may keep us from getting to critical points
in time.  Nobody I know of has bet long term on FlexJS.  Adobe can pull me
off at any time.  If we can attract a big corporation with a multi-person
development team to join in the FlexJS effort, they might bring in
professional doc writers and do a much better job than I would.  So today,
I think we're better off if I produce a TitleWindow for this new customer
that showed up yesterday than document the layout subsystem. My managers
would much rather that I help one or two customers migrate their code than
write documents so 100 folks can migrate on their own because we still
have enough bugs and missing features that the 100 would have little
chance of being successful, and making one or two folks successful is
likely to happen sooner than spreading energy over 100 customers and might
bring in that one big customer with the resources to really "move the
needle" and pave the roads for us.   And having a successful customer
improves the chances that Adobe will continue to pay me to work on FlexJS.
 Also, we don't have to agree.  If anyone thinks documentation is more
important, go write the documentation.  The key is to pursue your goals
without negatively impacting others.

Thanks again for working on this stuff,
-Alex

On 7/1/17, 3:40 PM, "Greg Dove" <gr...@gmail.com> wrote:

>Thanks Alex,
>
>I look forward to your feedback. It would be great to see  (from you or
>anyone else) -  within this thread - suggested improvements/corrections or
>other topics that should be added, or questions that should be addressed.
>
>I know there are areas that need improvement in a number of areas of the
>document, but I'm hoping that this will be 'fixed' by making it a shared
>goal and getting input from others, not by me kludging away in the
>background. I wanted to get something up that is a starting point only.
>
>I do understand the avoidance of the 'swiss army knife' approach to base
>classes in Flex 4, but had wondered about whether we were focusing on the
>19% of functionality that might be useful for 5% of developers (Basic) vs.
>the 20% of that will suit 80% of developers (e.g. express) -I'm not saying
> that the pareto relationships there are correct, just using it for
>'relative' comparison. But I think it is just a case of getting used to a
>new way to thinking, which is different to Flex4 (and Flex3). It would be
>really great if you can lead a thread specifically about this.
>
>I also suspect there will be no 'one true way' to make incremental
>functionality beads either. But documenting the pros and cons of each
>approach (which we already started in one of the other threads) might
>provide useful guidance about when to choose which approach (inheritance
>and/or utility functions etc). I'm looking forward to that discussion
>because I think I was getting a lot out of the earlier discussion on that
>already.
>
>In the end writing these things in a document is not something I call fun.
>"I'd much rather be coding". But I do believe that having 'team-sourced'
>content, as an output of focused list discussions, could make the
>generation of the document content a much easier process, and that the
>process itself could help  improve decision quality, build consensus, and
>provide resources that will be useful for team alignment and future
>reference info for others. I think any one of those reasons is enough for
>me to stop trying to create more of the content myself!
>
>
>
>On Sun, Jul 2, 2017 at 3:57 AM, Alex Harui <ah...@adobe.com.invalid>
>wrote:
>
>> Hi Greg,
>>
>> Thanks for writing this up.  I took a quick read.  I'll do a more
>>careful
>> read next week and have more detailed comments.  One thing I wanted put
>>up
>> for discussion now is the notion of "defaults".  Really, I'm trying to
>>get
>> away from the notion that there is one default we have to decide on.
>>IMO,
>> that's another old way of thinking from Flex.  FlexJS is designed to
>> support multiple component sets.  Express will have different defaults.
>> MDL has different defaults.  The Basic set has a particular design goal
>> (feature parity with SWF) and thus will have different defaults.  There
>>is
>> often no one right answer, so we build different component sets and
>>folks
>> will try them and decide for themselves.
>>
>> Thoughts?
>> -Alex
>>
>> On 6/30/17, 3:29 PM, "Greg Dove" <gr...@gmail.com> wrote:
>>
>> >Following on from other discussions, I have made a start on something
>>here
>> >https://na01.safelinks.protection.outlook.com/?url=
>> https%3A%2F%2Fcwiki.apa
>> >che.org%2Fconfluence%2Fpages%2Fviewpage.action%3FpageId%
>> 3D71013028&data=02
>> >%7C01%7C%7C35f519d4ea87431fd80808d4c0078bc3%
>> 7Cfa7b1b5a7b34438794aed2c178de
>> >cee1%7C0%7C0%7C636344586020292933&sdata=aj4YiAsUQDGoW5Bf%
>> 2BQ2wyJxgqmguZ18T
>> >Zng2jGcWIkY%3D&reserved=0
>> >
>> >In the end this will only work if people want to do it. But I do
>>believe
>> >that one way of getting everyone on the same page here (and we do have
>> >clear signs that not everyone is), is to, quite literally, get
>>everyone on
>> >the same page :).
>> >
>> >It is currently half content, half notes. There is more to harvest from
>> >list discussions I think, some topics have progressed further than
>>when I
>> >started trying to capture ideas, so please correct any mistakes in the
>> >definitions or add topics and questions that need
>>'resolution'/guidance.
>> >
>> >I personally would like to see some concrete guidance in the 'How does
>> >PAYG
>> >get implemented' section. There were definitely the beginnings of some
>> >healthy discussions around some of the options for beads for example.
>> >(DRY,
>> >inheritance, utility functions etc).
>> >
>> >The goal here is to turn any list discussions around
>> >uncertainties/misunderstandings into something that represents
>>consensus.
>> >I
>> >think this should be do-able by simple discussions about specific
>>topics,
>> >maybe with informal voting if necessary. If there is no consensus then
>>I
>> >guess PMC could do a formal vote? (I don't know what makes sense here)
>> >
>> >Beyond work on the SDK, this type of information (in some form) might
>>also
>> >be helpful as part of the documentation for 1.0 when we get there, so
>>it
>> >could save someone time later on as well as being useful in the near
>>term
>> >(I hope).
>>
>>

Re: [FlexJS] PAYG definitions and guidance, Please participate

[Greg Dove <gr...@gmail.com>]

Thanks Alex,

I look forward to your feedback. It would be great to see  (from you or
anyone else) -  within this thread - suggested improvements/corrections or
other topics that should be added, or questions that should be addressed.

I know there are areas that need improvement in a number of areas of the
document, but I'm hoping that this will be 'fixed' by making it a shared
goal and getting input from others, not by me kludging away in the
background. I wanted to get something up that is a starting point only.

I do understand the avoidance of the 'swiss army knife' approach to base
classes in Flex 4, but had wondered about whether we were focusing on the
19% of functionality that might be useful for 5% of developers (Basic) vs.
the 20% of that will suit 80% of developers (e.g. express) -I'm not saying
 that the pareto relationships there are correct, just using it for
'relative' comparison. But I think it is just a case of getting used to a
new way to thinking, which is different to Flex4 (and Flex3). It would be
really great if you can lead a thread specifically about this.

I also suspect there will be no 'one true way' to make incremental
functionality beads either. But documenting the pros and cons of each
approach (which we already started in one of the other threads) might
provide useful guidance about when to choose which approach (inheritance
and/or utility functions etc). I'm looking forward to that discussion
because I think I was getting a lot out of the earlier discussion on that
already.

In the end writing these things in a document is not something I call fun.
"I'd much rather be coding". But I do believe that having 'team-sourced'
content, as an output of focused list discussions, could make the
generation of the document content a much easier process, and that the
process itself could help  improve decision quality, build consensus, and
provide resources that will be useful for team alignment and future
reference info for others. I think any one of those reasons is enough for
me to stop trying to create more of the content myself!



On Sun, Jul 2, 2017 at 3:57 AM, Alex Harui <ah...@adobe.com.invalid> wrote:

> Hi Greg,
>
> Thanks for writing this up.  I took a quick read.  I'll do a more careful
> read next week and have more detailed comments.  One thing I wanted put up
> for discussion now is the notion of "defaults".  Really, I'm trying to get
> away from the notion that there is one default we have to decide on.  IMO,
> that's another old way of thinking from Flex.  FlexJS is designed to
> support multiple component sets.  Express will have different defaults.
> MDL has different defaults.  The Basic set has a particular design goal
> (feature parity with SWF) and thus will have different defaults.  There is
> often no one right answer, so we build different component sets and folks
> will try them and decide for themselves.
>
> Thoughts?
> -Alex
>
> On 6/30/17, 3:29 PM, "Greg Dove" <gr...@gmail.com> wrote:
>
> >Following on from other discussions, I have made a start on something here
> >https://na01.safelinks.protection.outlook.com/?url=
> https%3A%2F%2Fcwiki.apa
> >che.org%2Fconfluence%2Fpages%2Fviewpage.action%3FpageId%
> 3D71013028&data=02
> >%7C01%7C%7C35f519d4ea87431fd80808d4c0078bc3%
> 7Cfa7b1b5a7b34438794aed2c178de
> >cee1%7C0%7C0%7C636344586020292933&sdata=aj4YiAsUQDGoW5Bf%
> 2BQ2wyJxgqmguZ18T
> >Zng2jGcWIkY%3D&reserved=0
> >
> >In the end this will only work if people want to do it. But I do believe
> >that one way of getting everyone on the same page here (and we do have
> >clear signs that not everyone is), is to, quite literally, get everyone on
> >the same page :).
> >
> >It is currently half content, half notes. There is more to harvest from
> >list discussions I think, some topics have progressed further than when I
> >started trying to capture ideas, so please correct any mistakes in the
> >definitions or add topics and questions that need 'resolution'/guidance.
> >
> >I personally would like to see some concrete guidance in the 'How does
> >PAYG
> >get implemented' section. There were definitely the beginnings of some
> >healthy discussions around some of the options for beads for example.
> >(DRY,
> >inheritance, utility functions etc).
> >
> >The goal here is to turn any list discussions around
> >uncertainties/misunderstandings into something that represents consensus.
> >I
> >think this should be do-able by simple discussions about specific topics,
> >maybe with informal voting if necessary. If there is no consensus then I
> >guess PMC could do a formal vote? (I don't know what makes sense here)
> >
> >Beyond work on the SDK, this type of information (in some form) might also
> >be helpful as part of the documentation for 1.0 when we get there, so it
> >could save someone time later on as well as being useful in the near term
> >(I hope).
>
>