meego-sharing-framework:webupload-engine.git
7 years agoIf mime type was not known, we were printing a critical error and then setting 1 v0.3.4.1
divya [Tue, 25 Jan 2011 08:33:32 +0000 (14:03 +0530)]
If mime type was not known, we were printing a critical error and then setting
default mime type as text/plain. Changed it so we have failure if mime type
is not known

7 years agoWhen the file to be shared is deleted, it's entries from tracker get removed.
divya [Tue, 25 Jan 2011 07:14:36 +0000 (12:44 +0530)]
When the file to be shared is deleted, it's entries from tracker get removed.
Now, when the upload gets scheduled, the plugin tries to create a
WebUpload::Entry class from the given xml file. The init of WebUpload::Media
instance corresponding to the deleted file fails. We do not give an error
there, and try to continue with the init'ing of any other files to be shared
(which is 0 in this case). Now, when we try to do the actual upload, we see
there is no WebUpload::Media which has not been sent, and set state as upload
done.

Changes done:
(1) Tracker reading is done *AFTER* rest of the information is read from the
XML file
(2) Getting mime type, and original file path from tracker has been made
optional. So, if the file is deleted before it's upload is scheduled, then
not getting these does not indicate an error.
(3) Tracker mime type is used only if xml did not contain mime information
(4) With the above changes, a WebUpload::Media init will fail only if either
the XML file with the upload information, or tracker database is corrupted. In
either case, we should not continue with init of the WebUpload::Entry.
(5) Interaction with transfer-ui changed to handle the scenario where original
file link is not present.

7 years agoFixed compilation error
Mika Suonpaa [Thu, 20 Jan 2011 10:25:57 +0000 (12:25 +0200)]
Fixed compilation error

7 years agoFixed bug 219702.
divya [Thu, 20 Jan 2011 06:51:53 +0000 (12:21 +0530)]
Fixed bug 219702.

The issue was that the the state in PostBase was set to AuthPending even if
first error recovery needed to be done. The pointer to the AuthBase class was
being initialized only when the authentication check was started. If the
plugin was asked to stop after error recovery request was made, but before the
authentication was started, then we used to assert because of null AuthBase
pointer.

This is a very rare crash, but needs to be fixed. To fix, a new enum was added
to indicate that the PostBase class is in error fixing state. The rest of the
changes are done to ensure that states are changed correctly.

7 years agoAfter tagging
divya [Wed, 19 Jan 2011 11:04:03 +0000 (16:34 +0530)]
After tagging

7 years agoThe problem is that isActive() was changed to wait on the process exiting. When v0.3.3.1
divya [Wed, 19 Jan 2011 07:00:07 +0000 (12:30 +0530)]
The problem is that isActive() was changed to wait on the process exiting. When
the process exits, the member variable referring to the process was getting set
to 0 in the function PluginProcess::processFinished, but when the code in
PluginProcess::isActive after the m_currentProcess->waitForFinished(1000) was
executed, that variable was not checked against NULL value.

This bug can be reproduced with any service by disabling connectivity during
upload.

Changed back PluginProcess::isActive to return immediately with true or false,
depending on whether the plugin is running or not.

7 years agoChanged update process to only check for connection availability when plugin
divya [Wed, 19 Jan 2011 05:02:29 +0000 (10:32 +0530)]
Changed update process to only check for connection availability when plugin
gives failure. This allows the connection dialog to be handled properly,
and "No connection" error to be shown correctly.

7 years agoUpdating with review comment
divya [Tue, 18 Jan 2011 11:34:54 +0000 (17:04 +0530)]
Updating with review comment

7 years agoFix for bug 219643.
divya [Tue, 18 Jan 2011 07:08:01 +0000 (12:38 +0530)]
Fix for bug 219643.

Now, if a given upload is not the first in a queue, it will always how a
pending state which is something like "Waiting for previous upload to finish".
Only upload which is the first in the queue can have the other different
pending states.

7 years agoSome more tests and fixed bug 219582
divya [Mon, 17 Jan 2011 11:22:57 +0000 (16:52 +0530)]
Some more tests and fixed bug 219582

7 years agoUpdated test cases to increase some coverage
divya [Mon, 17 Jan 2011 06:48:49 +0000 (12:18 +0530)]
Updated test cases to increase some coverage

7 years agosmall fixes
Sami Viitanen [Fri, 14 Jan 2011 16:39:28 +0000 (18:39 +0200)]
small fixes

7 years agoFix log file name
Sami Viitanen [Fri, 14 Jan 2011 16:19:53 +0000 (18:19 +0200)]
Fix log file name

7 years agoAfter tagging
divya [Fri, 14 Jan 2011 08:23:02 +0000 (13:53 +0530)]
After tagging

7 years agoAdded ${misc:Depends} to the depends for libwebupload0-dbg to remove v0.3.2.1
divya [Fri, 14 Jan 2011 06:48:58 +0000 (12:18 +0530)]
Added ${misc:Depends} to the depends for libwebupload0-dbg to remove
the corresponding warning during debian build

7 years agoFixed some compilation issues.
divya [Fri, 14 Jan 2011 05:51:57 +0000 (11:21 +0530)]
Fixed some compilation issues.

7 years agoRevert wrong header change. Please be careful when you merge\!
Alexander Bokovoy [Thu, 13 Jan 2011 15:02:23 +0000 (17:02 +0200)]
Revert wrong header change. Please be careful when you merge\!

7 years agoFixed an issue where if new transfer was coming after the process thread exited,
divya [Thu, 13 Jan 2011 11:46:00 +0000 (17:16 +0530)]
Fixed an issue where if new transfer was coming after the process thread exited,
then it would get processed only when it became head of the queue.

7 years agoInitial commit
Alexander Bokovoy [Wed, 12 Jan 2011 16:34:40 +0000 (18:34 +0200)]
Initial commit