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
