[sword-devel] curl library and download termination

[Eeli Kaikkonen]

On Fri, 6 Nov 2009, Eeli Kaikkonen wrote:

> On Mon, 2 Nov 2009, Eeli Kaikkonen wrote:
>
> > > in getURL:
> > > - curl_easy_setopt(session, CURLOPT_PROGRESSDATA, statusReporter);
> > > + curl_easy_setopt(session, CURLOPT_PROGRESSDATA, this);
> > >
> > > in my_fprogress:
> > > - ((StatusReporter *)clientp)->statusUpdate(dltotal, dlnow);
> > > + ((CURLFTPTransport *)clientp)->statusReporter->statusUpdate(dltotal,
> > > dlnow);
> > > + return ((CURLFTPTransport *)clientp)->term;
> >
> > These changes should be correct, and I don't find anything else to add
> > or change regarding the curl library.
>
> ../include/ftptrans.h:53: error: ?sword::StatusReporter*
> sword::FTPTransport::statusReporter? is protected
> ../src/mgr/curlftpt.cpp:78: error: within this context
> ../include/ftptrans.h:55: error: ?bool sword::FTPTransport::term? is
> protected
> ../src/mgr/curlftpt.cpp:81: error: within this context
>
> It's probably possible to add some getter methods without breaking
> binary compatibility. Is that acceptable? Another possibility might be
> to make m_fprogress a static method of CURLFTPTransport. I'm researching
> this.

"private: static my_fprogress" worked. Also the whole system worked with
BibleTime, even better than expected.

However, when I tried to test it with Xiphos the app failed to install
modules every time right after beginning. It didn't recover even when I
changed back to standard sword package. I used LD_LIBRARY_PATH, I didn't
compile Xiphos. I'm not sure if this was the reason for the error
because it shouldn't affect after using different library binary.

Another thing is that return values of functions are buggy. InstallMgr
finally returns -1 independently from what really happens. If I cut the
net connection it returns the same value than when the user cancels
download. I don't think it's right thing to do. The frontends can of
course detect whether user has cancelled but it doesn't make the library
behaviour correct. I don't know how serious this is because until now
frontends have worked with current implementation.

So, what shall we do next? I can just say "it works for me". But this
needs good testing before a release. Other developers must help. I can
create a patch which can be tested manually or via svn.

  Yours,
	Eeli Kaikkonen (Mr.), Oulu, Finland
	e-mail: eekaikko at mailx.studentx.oulux.fix (with no x)