[tahoe-dev] Dedicated LAFS nodes offer

[Callme Whatiwant]

Just a response about "worse is better" / "correctness" and LAFS development:


On Fri, Jul 26, 2013 at 9:52 AM, Avi Freedman <freedman at freedman.net> wrote:
>
>> Avi,
>>

[snip...]

> It'd be better if LAFS grew in features and usability, though.  I
> think sometimes the religion of the correctness of approaches
> dominates the creativity towards coming up with expedient ways of
> doing/using LAFS tech in such a way as to be parallel and less
> secure/private than 'correct' usage.
>

Sometimes I feel like LAFS has too many features!  ;-)

My preference is to keep LAFS itself as small and "correct" as
possible and add features at a glacial pace.  Then, in addition, a
community of related services code can be developed independently.
This only works for features which can be cleanly layered, and
layering can add extra integration complexity or runtime overhead.
Yet I still learn this way architecturally.

Which features do you want which you feel the core lafs codebase is
implementing too slowly by dint of being "too correct"?  Let's
implement worse-is-better alternatives for those features now outside
of the core codebase!  If it's not possible without modifying the core
codebase, then that will inform the development of the slower more
correct feature.

My inclination is to put the brakes on adding features to lafs, where
possible, and instead implement them outside of lafs.  I believe this
allows more rapid development of more use-case specific features at
some cost to runtime overhead.  After the new feature is rapidly
developed and working with high overhead, the core lafs design can be
informed by that, and may be augmented to support that "external
feature".

>
> Thanks,
>
> Avi
>


nejucomo