https://bugs.kde.org/show_bug.cgi?id=199145--- Comment #11 from Siu Chung (Clement) Cheung <clement cc gmail com> 2009-11-25 11:42:52 ---
Alright, I think I know why. Used Wireshark to capture all the packets. The
requests are all sent correctly and Google received them. Even returned a "201
Created". But if you look closely at the Google API, they don't implement
locking (probably for performance reasons). The way to update something is to
download the whole thing and then upload the whole thing. Now consider this
sequence:
1. Get tags to add tag 1 (received no tags)
2. Get tags to add tag 2 (received no tags)
3. Set tags to nothing + tag 1. Send.
4. Set tags to nothing + tag 2. Send.
Now tag 1 is lost. Classic race condition.
If I add a dialog box after every add tag message, it works. Also, the last tag
never get lost. That makes me think this is the problem. The Google recommended
solution is to use etags. Except that we can't. Because we're updating the tag
entry here, not the photo entry. This is an oversight on Google's part IMHO.
But not all hope is lost. :-)
I studied the official Google libraries and I found that they do this:
1. Upload picture.
2. Use response to construct photo entry object
3. Add keywords and everything to photo entry object
4. Call commit on the photo entry object to send changes.
On the wire, this is what happens:
1. Upload picture using HTTP POST
2. Server returns ATOM with all metadata of this picture
3. Library parse this XML into photo entry object
4. Caller modifies photo entry object
5. Caller commits
6. Library constructs new XML and do an HTTP PUT.
All we need to do is to emulate that and add all tags in one shot. (only one
tag request hence no race conditions)
1. Upload picture using HTTP POST
2. Server returns ATOM/XML with all metadata
3. We parse and modify this XML. Add all the tags we want.
4. Send back this XML using HTTP PUT.
This approach has the advantage of allowing other stuff such as Geotags in the
future. We can specify that explicitly for image files where Google fails to
parse the IPTC Geotags. (saw some bugs on bugs.kde.org) All done in a single
shot.
I've made a new patch. Seems to work. Tested with around 30 photos with 6 or 7
tags each. All arrived correctly. Feel free to change the coding style if you
don't like it. Future wish: would be nice if someone can parallelize the
picture resizing. You could resize the next picture while this picture is
uploading.
--
Configure bugmail:
https://bugs.kde.org/userprefs.cgi?tab=email------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Kde-imaging mailing list
Kde-imaging@...
https://mail.kde.org/mailman/listinfo/kde-imaging
