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.
stuff like stream.h should probably be moved to the utils library.
On Wed, Mar 16, 2011 at 10:05 PM, Marc-André Moreau <
marcandre.mor...@gmail.com> wrote:
>
>
> On Wed, Mar 16, 2011 at 9:29 PM, Mads Kiilerich <m...@kiilerich.com>wrote:
>
>> Marc-André Moreau wrote, On 03/17/2011 02:05 AM:
>>
>> Maybe we can deal with the problem this way:
>>>
>>> each "package" or library gets its folder in include/freerdp. For
>>> instance, we would have:
>>>
>>> include/freerdp
>>> include/freerdp/utils
>>> include/freerdp/chanman
>>> include/freerdp/gdi
>>> include/freerdp/kbd
>>>
>>> Each of those "packages" would have a "global" header file, like this:
>>>
>>> include/freerdp.h
>>> include/freerdp/utils.h
>>> include/freerdp/chaman.h
>>> include/freerdp/gdi.h
>>> include/freerdp/kbd.h
>>>
>>> where each of those "global" headers would include all of the headers
>>> within the associated subdirectory. Am I making sense? I'm just trying to
>>> think of a cleaner way to organize things.
>>>
>>
>> That would be very consistent, but it wouldn't reflect that the libraries
>> have different natures: For utils it is a bad idea to use utils.h - instead
>> the specific utils/something.h should be used. For for example kbd only
>> kbd.h should be used - there is hardly any reason to use kbd/something.h
>> directly.
>>
>
> I agree, but sometimes architectural consistency is more important to avoid
> confusion. We could provide a utils.h without ever using it, just to
> maintain that consistency. As for kbd/something.h, there is always the case
> where you would want locales.h or keyboard.h that contain important constant
> definitions.
>
>>
>> I would suggest that we drop utils.h and that we put all the content of
>> for example kbd/*.h into kbd.h and drop the subfolder.
>>
>
> If you want to merge keyboard.h + locales.h + kbd.h, it's going to be a
> mess, they're quite big. As I said above, for kbd, it might be a good thing
> to have for instance include/freerdp/kbd/locales.h.
>
>>
>> It also seems inconsistent that the headers for libfreerdp should live in
>> include/freerdp/*.h and be aggregated into include/freerdp.h . libfreerdp
>> might be the primary entry point, but the other libraries are not
>> particularly subordinate to it. I think it would be better to have
>> include/freerdp/freerdp.h (and perhaps but preferably not
>> include/freerdp/freerdp/*.h). We could perhaps also come up with a more
>> specific name for this library - for example "rdp" or "protocol".
>>
>
> Yes, for the sake of consistency, we should probably drop the libfreerdp
> prefix and use something else for libfreerdp itself. Maybe librdp would
> actually reflect the fact that it should be concerned with the core RDP
> protocol. It would give something like this:
>
> #include <freerdp/rdp/nego.h>
>
> However, just by writing this, the repetition of the "rdp" makes it look
> weird. Maybe we could call it "core" instead since it should be reserved for
> the RDP core protocol:
>
> #include <freerdp/core/nego.h>
>
>>
>> A final nit in this ballpark: when working with the source code it is a
>> bit annoying that everything is called libfreerdpsomething. It gives longer
>> paths that isn't very easy to read and makes command line navigation harder
>> - even with tab completion. We could perhaps drop the libfreerdp prefix
>> internally.
>>
>
> I agree, it is also highly confusing. For instance, just to refer to
> libfreerdpgdi, you actually have to use "libfreerdpgdi" instead of "gdi".
> Reading a couple of "libfreerdp-something" makes it hard to quickly
> distinguish which one is which.
>
>>
>> /Mads
>>
>>
>
------------------------------------------------------------------------------
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
_______________________________________________
Freerdp-devel mailing list
Freerdp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freerdp-devel
