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
