[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