[sword-devel] curl library and download termination
Eeli Kaikkonen
eekaikko at mail.student.oulu.fi
Sat Nov 7 06:14:31 MST 2009
On Fri, 6 Nov 2009, Troy A. Griffitts wrote:
> Yeah, Eeli, I would guess Matthew is correct about your changes breaking
> binary compat, though I HOPE we haven't broken binary compat since 1.6.0.
>
As I wrote, I didn't find any indicator in the KDE document that adding
a static member function would break compatibility, but not vice versa
either. Adding a non-static non-virtual member function doesn't break
compatibility.
> Safe rule to follow is not to change anything in header files needed to
> compile a frontend app. For example, we've added canon*.h header files
> since 1.6.0, but those header files should only be required when
> building the engine-- not when building BT, Xiphos, etc.
>
True, it's safe, but more can be done and still be safe. However, that's
not the point here. We just have to find a practical safe solution:
> Back to a solution....
>
> I guess we can we just do things the long cheesy way now with some silly
> static class definition in CURLFTPTransport.cpp:
>
> struct PrivateData {
> PrivateData(CURLFTPTransport *t, StatusReporter *sr) : trans(t),
> statRep(sr) {}
> CURLFTPTransport *trans;
> StatusReporter *statRep;
> }
>
> Then:
> PrivateData p(this, statusReporter);
> curl_easy_setopt(session, CURLOPT_PROGRESSDATA, &p);
I have to try this.
Another possibility might be to declare my_progress as a friend of the
classes, but it would probably work for subclasses only if it depended
on private implementation in curlftpt.cpp file, i.e. my_progress
prototype would be made known to the sublasses.
> I agree, the return value should do more than just return -1 on anything
> other than CURLE_OK.
It's not just curlftptransport but ftptransport and installmgr, too.
There are some functions which have several returns in several
occasions, so it's not simple enough for me to fix it quickly. I would
appreciate if someone who has been involved writing it could review it.
Yours,
Eeli Kaikkonen (Mr.), Oulu, Finland
e-mail: eekaikko at mailx.studentx.oulux.fix (with no x)
More information about the sword-devel
mailing list