Alex, and Harbs, Thanks for pointing that out. Actually I will have defifintely looked through this early on, but I'd have to say it is quite 'light' on what PAYG actually means beyond the general sense that I had. It does have some more detail about beads which is great and I could have benefited from revisiting that in recent months which I did not do.
But I can see that the newly created 'DRY' discussion thread is actually creating the type of content that I think I would have found really helpful in terms of linking a guiding concept to one of its key implementation areas. Creating this type of documentation is *hard*. Not just because creating the content itself is a lot of work, But also because it is not (usually I think) something that a developer wants to do, especially when volunteering their time. "I'd much rather be coding". So thanks Alex for what you already created there. However, I think the contents of the new thread look really good as something that could be used as a resource to define bead variation in terms of PAYG adherence, as an implementation guide, and I do think we really need this. If there's that level of clarity and, ultimately, agreement in terms of definitions and approaches, I expect there will be far less need for threads like this one. If no-one else volunteers to wiki-fy the contents of the new thread at its conclusion, I will give it a shot over the coming weekend. On 2017-06-06 18:55 (+1200), Alex Harui <aha...@adobe.com.INVALID> wrote: > This was first published in 2012. > > https://cwiki.apache.org/confluence/display/FLEX/Alex's+FlexJS+Prototype > > PAYG and avoiding just-in-case code is mentioned in that document. As are > Beads. > > Thanks, > -Alex > > On 6/5/17, 11:33 PM, "Greg Dove" <greg.d...@gmail.com> wrote: > > >Harbs, a quick comment from the sidelines on: "PAYG is already well > >understood" > > > >I don't really think that is the case, at least it has not been for me. I > >had a more general notion of PAYG that was nothing to do with beads at > >all, > >and was limited to guesswork/my own interpretation of it at the beginning > >because there was no clear definition. > > > >Unless this is documented somewhere then I believe it is actually a > >barrier > >(of understanding) for people getting involved. If there's already a > >difficulty with 'thinking this way' and 'acting this way' as you indicated > >when you had started and had understood it, then it seems important that > >it > >should also be easily understood in the first place in order to make > >things > >easier for people wanting to participate. > > > >As with a lot of things, once you 'know' it you can tend to take if for > >granted that everyone else does too. But I think you already hinted at > >that > >with what you said... > > > >I am of the opinion that 'vision', 'mission', 'goals' and even > >'architecture' etc don't really exist in a form that is useful for shared > >understanding unless they are documented in some way. And no, 'it's > >obvious > >from the source code' is not what I mean :). > >They are not considered to do so in many other scenarios, in any case, and > >I can't understand why it would be different in an open source project, > >although I definitely have not spent time comparing projects to find out > >what others do here. > > > > > >On Tue, Jun 6, 2017 at 5:21 PM, Harbs <harbs.li...@gmail.com> wrote: > > > >> Weâve all already been implementing things as Alex states. He > >>architected > >> the framework and itâs a good architecture. No need to change things. We > >> need consistent architecture. We canât have a free-for-all... > >> > >> Percentage of code really has nothing to do with it. Unless something is > >> functionality that you would (virtually) always need, itâs a separate > >>bead. > >> Thatâs the way the whole SDK is implemented. If there are cases where > >>itâs > >> not, itâs a bug and should be fixed. Removal of password functionality > >>is > >> NOT usually required for password beads. > >> > >> PAYG is already well understood: All functionality should be implemented > >> as beads when practical. Beads should be as modular as possible with the > >> smallest possible functional set. > >> > >> Thatâs pretty much it. Itâs difficult to make the mental switch to > >>working > >> this way. I had similar difficulty when I started implementing things > >>for > >> FlexJS. It takes some getting used to, but itâs a very good design. > >> > >> Harbs > >> > >> > On Jun 6, 2017, at 1:16 AM, Justin Mclean <jus...@classsoftware.com> > >> wrote: > >> > > >> > Hi, > >> > > >> >> If you have a different vision, you can execute that vision in > >>another > >> >> component set or fork FlexJS entirely. Please do not impose your > >>vision > >> >> on my vision. > >> > > >> > Since when is this your project Alex or that the project has to only > >> include your vision? That is not the Apache way. > >> > > >> > I would prefer that we all come to a consensus of what PAYG means and > >> clearly document it rather that you dictating it. > >> > > >> > Thanks, > >> > Justin > >> > >> > >
