Moving libkfacebook to extragear

[Martin Klapetek]

On Sun, Oct 28, 2012 at 8:03 PM, Kevin Krammer <krammer at kde.org> wrote:

>
> > This is for the parsing purposes - the library uses QJson parser/mapper,
> > which automagically maps the received json data to qobjects, otherwise
> > there would have to be manual parsing everywhere (and the facebook jsons
> > are huge), which means more code, more error possibilities, more
> > maintaining requirement and worse readability (compared to two lines
> QJson
> > mapper). So I'd like to leave this one as is.
>
> I haven't had a look at the QJson library internals (yet), but from its
> usage
> it looks like that it is only using instances of those QObject classes to
> provide a convenient mapper of map keys to conversion functions (the
> property
> setters).
>
> This would make them an internal implementation detail, something more
> convenient than manually writing a mapping of string to function pointer
> but
> also just private.
>
> As I said I'll have a look into QJson, but unless I am gravely mistaken it
> only needs such QObjects as a generic accessor API, not as the actual data
> object.
>

Thanks. I fixed all the issues you pointed out except this one.

Also I checked for the naming and here's what I found [1]:

  6. You may not combine our Brand Assets, or elements of our Brand Assets,
with your own name or mark or generic terms.

So if "lib" is a generic term, "k" is sort of our mark, I guess
"libkfacebook" is pretty much off limits, right? Either way, we might be
just better off changing the name and rest calm. I'm thinking going in
steps of "libkgapi" - "libkfbapi". Thoughts?

[1] - https://www.facebook.com/brandpermissions/logos.php

Cheers
-- 
Martin Klapetek | KDE Developer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20121029/062e5cab/attachment.htm>