The wiki from 4 years ago is very helpful in understanding architectural decisions: https://cwiki.apache.org/confluence/display/FLEX/Alex's+FlexJS+Prototype <https://cwiki.apache.org/confluence/display/FLEX/Alex's+FlexJS+Prototype>
If you have suggestions to make things clearer then by all means suggest something. Thanks, Harbs > On Jun 6, 2017, at 9:33 AM, 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 >> >>
