About ProgressReport and msn-pecan

[Felipe Contreras]

Hi Richard,

On Fri, Jun 13, 2008 at 8:45 PM, Richard Laager <rlaager at wiktel.com> wrote:
> On Fri, 2008-06-13 at 15:40 +0300, Felipe Contreras wrote:
>> You have a tendency to want to do everything by yourselves, that's why
>> I brought the point. I'm glad that things are working well now,
>> hopefully it will stay that way. But still, is it so crazy to leave
>> the project hosting to, I don't know, project hosting experts?
>
> With regard to the website, I don't think there's much we could do
> differently there. If we had a hosted website instead of a (virtual?)
> server, we'd still have the same content.

Indeed, not right now, but at least it should be under consideration.
So you focus on the things that really matter instead of figuring out
which piece of code is eating cpu from the server.

>> > I don't know what "mess with header includes" you're referring to.  As far
>> > as I know most of the headers are reasonably laid out and functional.
>>
>> Please refer to this picture:
>> http://people.freedesktop.org/~felipec/connection_h_dep.png
>>
>> Do you think that's not messed up? Sure, it could be worst, but that's
>> not the point.
>
> I think that diagram is irrelevant. connection.h includes only 4 headers
> from libpurple, which it needs. We also now have purple.h to simplify
> the lives of plugin authors. If you have a *concrete* change to suggest,
> please do.

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.

For an explanation with diagrams check:
http://felipec.wordpress.com/2008/01/27/msn-pecan-006-released/

>> > Object oriented code is certainly a design goal of gobjectification, or have
>> > you not been paying attention to that whole discussion?
>>
>> I haven't seen a consensus among developers, some people want that,
>> others argue that's not required. All I know is I don't see any 3.0.0
>> branch.
>
> Who is not in favor of gobjectification? The problem here is a lack of
> time by interested people. If you want to help here, please do.
>
> $ mtn list branches | grep gobject
> im.pidgin.gobjectification
>
> See my reply below, though.
>
>> > And I'm sure we'd like to work toward supporting reasonable freedesktop.org
>> > standards.  Which ones are we so blatantly and offensively disregarding in
>> > your eyes?
>>
>> For starters; ~/.purple.
>
> I assume you meant this, which is actually a freedesktop.org spec and
> not a path name:
> http://standards.freedesktop.org/basedir-spec/basedir-spec-0.6.html
>
> First off, dot directories pre-date that standard by probably decades.
> Second, there are still a lot of projects using them, so it's not like
> we're the last holdout. Third, we've discussed that before:
>
> Moving data from ~ to ~/.local/share doesn't really buy you much.
> Instead of having a ~ cluttered with directories, you have a
> ~/.local/share cluttered with directories. The /etc to /etc/xdg change
> is basically the same. That spec seems to have a couple of advantages:
> 1) It provides a common environment variable that can be used to allow
> users to move their configuration files. 2) It splits out cache data
> (like buddy icons, in our case), which is nice when you're doing ~ on
> NFS or similar (or roaming profiles on Windows). The downside to
> splitting the data is that instead of a ~ cluttered with directories,
> you end up with *multiple* directories cluttered with directories.
>
> That said, I don't have a problem supporting that spec for 3.0.0. It'd
> have to be a 3.0.0 change because it would break backwards compatibility
> of the configuration files. I don't think that the minor benefits gained
> are worth forcing a major version bump just now. If this is really
> killing a use case for you or someone you want to support, I'd propose
> you add the support now as a configure option that defaults to off. We
> can then remove the option (and turn it on) for 3.0.0.
>
> In fact, if we decide to follow this spec, we should probably add
> support for *looking* in that location sooner. For example, let's say we
> add support for looking at the XDG locations in 2.6.0: if it found a
> configuration directory in those locations, it would use it. Otherwise,
> it would fall back to ~/.purple. However, it would still create
> ~/.purple by default. That way, 2.6.0 would be forwards compatible with
> 3.0.0, which would create $XDG_xxx/purple, etc.

Sounds reasonable. I still think all that configuration stuff should
be handled by the client, not the library, but that's for another
flamewar ;)

>> I separate the cleanup changes from the relevant ones.
>
> Here was one example that Kevin mentioned. I'm not going to take a
> position as to whether this is an isolated example or a trend, because I
> haven't looked at your revision history:
> http://github.com/felipec/msn-pecan/commit/40c0bbedef9baec773b9975aad8d1ffde2a02a8c
>
>> I know you can't keep up with the fast development in msn-pecan, I
>> won't slow it down for some "hypothetical merge".
>
> Fast development is great. Kevin's comment is about revisions like the
> one above, where the commit message says one thing and there are big
> unrelated changes there. That could easily have been committed as two
> revisions, which would reduce* this concern without slowing down
> development more than a few seconds.
>
> * I say reduce rather than eliminate because in this particular case,
> the functions were renamed for no apparent reason. However, if a cleanup
> or refactoring change were legitimate, it still should be done
> separately.

Ah, that's just a change that slipped off. I usually double, or triple
check the commits. Definitely not intended.

>> The change I'm more interested in is GObjectification. I've been told
>> that such change requires API breakage and so it must wait for 3.0.0,
>> but that's not true, I've explained that you can have internal API
>> changes and still keep the external old API with a wrapper. I know
>> because I started doing exactly that years ago.
>
> If you can GObjectify structures in place, great. By all means, please
> go ahead with this if you'd like. I can review patches for you if you'd
> like.

Sorry, I've lost more than enough time with libpurple. While I'm still
interested in doing things now I've realized that there are more
interesting things to do, like create a Telepathy connection manager
that uses msn-pecan, so GObjectification is now pretty low on my to-do
list.

>> 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.

Best regards.

-- 
Felipe Contreras