Fwd: Re: msn-pecan now has direct connection support (fast file transfers)

[Gary Kramlich]

John Bailey wrote:

<snip>

>> This is a big part of the problem.  When I am finally able to sit down
>> and knock out some objects, I spent the majority of the time explicitly
>> merging my way back up to i.p.p:h.
> 
> It sounds like at this point it would be easier to get your individual diffs and
> restart on a fresh branch when you can actually dedicate time to it?

That won't work.  I mean, I can't merge the objects into i.p.p:h, and
the majority of the time it doesn't fully build anyways so it can't be
merged into i.p.next.major:h.  In other words, the moving target issue
will not be solved by branches.

I think the best way to explain this goes as follows.  You know how we
always laugh at the people that want to fork.  Yeah, same issue, I'm
redesigning basically the entire library.

A few things that will help, but won't until development on i.p.p
becomes maintenance only, is structure member hiding.  I'm doing that as
well as the object hierarchy at the same time, and the usage of
structure members is what 99% (rough estimate) of the build failures are.

>> I see the flexibility as the key factor here.  It gives us the
>> opportunity to change the version of a protocol via the configure
>> script.  For example, say we know msnpX is going to be turned off at a
>> certain point and time, so all we do is tweak an AC_DEFINE or m4_define
>> and we're using msnp11.  By a configure option, I don't mean just a
>> --with-msnp15 or something, but just a central place to decide which one
>> is built.  We could allow multiples, but I don't see that as exactly
>> necessary.
> 
> Right now I'd rather see us get MSNP11 support in our existing P9 plugin and
> stabilize 15 for future release.  I think Stu is also of the opinion of wanting
> to get PSM support by implementing P11, although I'm sure he'd like to forget
> the rest of the newer protocol versions.
> 
> Flexibility is good, yes, but if P11 support was already *done* in Felipe's
> existing patch, surely it could be tweaked/retooled as necessary and merged to
> get us to P11.  At that point we could forget about P9 except for any potential
> use as a stable reference point.

Right, ultimately I don't care what version of the protocol that we
actually end up using.  But keeping the existing code around and in
working order (as long as the server still allows it), seems like the
right thing to do.  Mind you, I'm also the guy that saved the napster
prpl from the bit bucket and then let it bit rot until you fixed it :)

> John

-- 
Gary Kramlich <grim at reaperworld.com>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
URL: <http://pidgin.im/pipermail/devel/attachments/20071230/5c3a1d14/attachment.sig>