[LAD] NSM - handling large files

[J. Liles]

On Wed, Apr 4, 2012 at 5:22 AM, Rui Nuno Capela <rncbc at 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...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxaudio.org/pipermail/linux-audio-dev/attachments/20120404/8425ff7e/attachment.html>