[sldev] Proprietary dependencies [2] (Re: Compile as installer)

[Dzonatas]

Lawson English wrote:
> Rob Lanphier wrote:
>> [...]
>> At a gut level, I'd much prefer to get rid of proprietary 
>> dependencies.  If nothing else, it makes my job easier, but I also 
>> philosophically prefer that we remove them sooner rather than later.  
>> I just don't feel like I yet have a watertight business and community 
>> case to make that we should perhaps take steps backwards in features 
>> and functionality in order to get rid of those dependencies.
>>
>> Rob
> My own take is that things are so messy in the current client that 
> complaining about this kind of thing is futile anyway. Until the 
> client is factored properly any changes that are made by an 
> inidividual are bandaides on bandaides.

What is not clear is why either proprietary or open-source dependencies 
has any affect of progress of the of the product.  This is said with 
attention being brought to the monolithic design of the client code 
being bundled as static libraries under one single executable. It has 
not been made clear to the community why that is being done. Any 
argument to choose between proprietary or open-source dependency is held 
back by the reason to keep libraries as static links.

We've heard the issue saying that it makes installation easier, but that 
is all that is being said. If the installation scripts and procedure 
were made to handle dynamic libraries, the issue of there being a 
proprietary or open-source library attached become really a non-issue as 
long as they are dynamically linked.

That is one part there.

Further, the client code could change separate out its features into 
different processes or tasks. Surely there is no need to keep every 
piece of the entire client to run in synchronous fashion under a single 
CPU. For one, the sound system could be put into another asynchronous 
process such that it is just passed a URL to play. Is there any example 
of this being done now, yes, the voice client is a separate asynchronous 
task, and it sits in its own module separate from the client. That is 
how regular sound should work also in its own module. Let LL distribute 
its proprietary module and others distribute the open-source 
alternative. Between the tasks, there just needs to been an API standard.

No more bickering about proprietary dependencies and no more running in 
circles about saying it makes the installing easier, please.  Let's just 
agree to a standard API.