Documents like this could be used:
http://www.eetimes.com/design/embedded/4023876/Modular-Programming-in-C
<http://www.eetimes.com/design/embedded/4023876/Modular-Programming-in-C>We're
using something similar already in different places, but we might want to
formalize it, document it on the wiki, and enforce it such that all FreeRDP
"modules" are consistent.
On Mon, Mar 21, 2011 at 8:14 PM, Marc-André Moreau <
marcandre.mor...@gmail.com> wrote:
> 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
