About ProgressReport and msn-pecan

[Felipe Contreras]

On Sat, Jun 14, 2008 at 3:43 AM, Richard Laager <rlaager at wiktel.com> wrote:
> On Sat, 2008-06-14 at 02:08 +0300, Felipe Contreras wrote:
>> I have suggested the change before; If you split account.h into
>> account_private.h then when you include account.h you only include
>> that, no need to go thousands of levels deeper.
>
> I don't understand. What part of account.h would get split into
> account_private.h? Or, alternatively, what would be left in account.h.

account.h:
typedef struct PurpleAccount PurpleAccount;

account_private.h:
struct PurpleAccount
{
	char *username;
	char *alias;
	char *password;
	char *user_info;
	...
	PurplePresence *presence;
	...
}

That means that if you include account.h you can't do
account->username, because "account" is an incomplete type, just like
a void *. Note also that PurplePresence doesn't need to be defined in
account.h, hence you remove a header dependency for all the files that
include account.h, and you remove all the headers that presence.h
include, and so on.

After cleaning up that mess in msn-pecan compilation time was reduced
quite dramatically. You should try to the some in a few places ;)

Oh, now I remember a criticism to this approach. Somebody mentioned
that this breaks the API. But again, that's not true. The account.h
that gets installed doesn't need to be the one used internally.

For example, account.h could be split into account_public.h and
account_private.h. Stuff in libpurple would use one of these two
headers, preferably the public one. Then, account.h includes them
both.

>> like create a Telepathy connection manager
>> that uses msn-pecan
>
> If you got msn-pecan merged, telepathy-haze would already give you this
> functionality. ;) I realize that may not be the best solution, though.

I can already do that, but why not remove the middle man's if
libpurple is so painful to use?

>> >> I've also been told that there are no more fileds available for prpl
>> >> structures, which I find stupid because at least one field could have
>> >> been used for storing the version, making it extensible.
>> >
>> > This is exactly what has been done to overcome this problem.
>>
>> Has been done? I was being told that wasn't possible anymore, not until 3.0.0.
>
> Someone used the last struct member in a change on ipp.next.minor.
> (Looking at the code, it was the addition of the explanatory strings for
> the account editor's username box.) We hadn't released that code, so it
> was fixed up.

Great! I propose an API version field, then.

Best regards.

-- 
Felipe Contreras