On Mon, Mar 21, 2011 at 9:03 PM, Mads Kiilerich <m...@kiilerich.com> wrote:
> Marc-André Moreau wrote, On 03/22/2011 01:14 AM:
>
>> Hi Mads,
>>
>>
>> On Thu, Mar 17, 2011 at 8:30 AM, Mads Kiilerich <m...@kiilerich.com<mailto:
>> 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.
>>
>
> I think what we have now with header files and implementation is OK. We
> don't need rules for that - just common sense. We should for example not
> instantiate values in header files (also not constants), and we should not
> put stuff in header files unless there is a good reason to do it.
>
> We could however document more clearly what the intention with the
> different modules is and which dependencies are acceptable. A map could be
> helpful.
>
This is something that we can easily introduce with doxygen :) We can
declare sources as being part of a particular module, and then even tell
doxygen to generate dependency graphs between those modules, hehe.
>
> I think it would have bigger value to document the coding/formatting/naming
> style. That is an area where common sense can't be used, so it must be
> written down, hated, and followed.
>
Yes, this is what I meant by "formalizing, documenting, and enforcing" ;)
>
> /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
