Hi Mads,

On Thu, Mar 17, 2011 at 8:30 AM, Mads Kiilerich <m...@kiilerich.com> wrote:

> On 03/17/2011 03:19 AM, Marc-André Moreau wrote:
>
>>
>> There is also some stuff that should probably be moved out of
>> libfreerdp. We could make the following modules:
>>
>> auth: credssp, ntlmssp, and eventually kerberos.
>> crypto: all the crypto_, tls_, and secure.c.
>>
>
> Please, let us be pragmatic. There is no need to create separate libraries
> with public APIs for everything. We can do modularisation without creating
> separate libraries for each "module".
>

I agree with you: we do not need public APIs for everything. making
libraries with "public" APIs which is in fact only used internally is
confusing and unneeded. On the other hand, I would really like to find a
clean way of creating software modules for internal source code
organization.

Ideally, if there are already established coding standards used in other
projects written in C that do exactly that, maybe we could take inspiration
from them. Any ideas on how to enforce a particular way of "declaring"
modules, without making libraries? I agree that making libraries with public
APIs is not the way to go, I'm just looking for some good way to achieve the
same for internal use.

>
> It has some relevance to split optional functionality out in libraries so
> the dependencies (to for example pulseaudio and cups) are optional. As a
> consequence of that we might need some common shared utils. Going beyond
> that will in my opinion have a maintenance overhead but no benefit.
>
> I think it is fine to have the choice of crypto backend as compile time
> option. If somebody some day see a use case for using your credssp/ntlm/nla
> stuff in another project it can be made a separate library - that probably
> no longer should be a part of libfreerdp. There is no need to focus on that
> now.
>
> /Mads
>
------------------------------------------------------------------------------
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software 
be a part of the solution? Download the Intel(R) Manageability Checker 
today! http://p.sf.net/sfu/intel-dev2devmar
_______________________________________________
Freerdp-devel mailing list
Freerdp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freerdp-devel

Reply via email to