Just a response about "worse is better" / "correctness" and LAFS development:
On Fri, Jul 26, 2013 at 9:52 AM, Avi Freedman <freed...@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 _______________________________________________ tahoe-dev mailing list tahoe-dev@tahoe-lafs.org https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
