flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Dove <greg.d...@gmail.com>
Subject Re: [FlexJS] Removing PasswordInputBead has no effect
Date Tue, 06 Jun 2017 06:33:49 GMT
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.lists@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 <justin@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
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message