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 > >
