Re: [LAD] NSM - handling large files

On Wed, Apr 4, 2012 at 5:22 AM, Rui Nuno Capela &lt;rncbc(a)rncbc.org <mailto:rncbc@rncbc.org>> wrote: On 04/04/2012 12:18 PM, rosea.grammostola wrote: On 04/03/2012 07:04 PM, Rui Nuno Capela wrote: now, i could suggest NSM API to be split in levels of compliance and restrictiveness, so to speak: - level 0 :- clients just store/retrieve their own private state from a supplied and independent session sub-directory; no GUI File menu restrictions; no file location restrictions, no symlinks, no juggling, no dupes, no sh*t. - level 1+ :- anything that (may progressively?) imposes each one the mentioned non-restrictions of level 0. How much more effort will it be in terms of coding, to implement 'level-1' versus 'level-0'? speaking from qtractor pov.: - level 0: minimal effort as it would be a probable and simple rephrasing and/or adaptation of the code already in place for jack-session; also, there's this osc branch somewhat lurking in svn to get readily merged and apply for the NSM/OSC interface. - level 1+: pervasive change and effort; almost brand new application overhaul (iow. won't happen any time soon:) sorry. Are you seriously saying that the equivalent of doing: if ( nsm_is_active ) save_here( file ); else save_there( file );

Would require a complete rewrite and overhaul of your application? Say you don't want to do it... That's fine. Say you don't like the NSM design--that's fine too. But don't just make up wild hyperbole out of laziness...