GSoC/2018/StatusReports/ThanhTrung: Difference between revisions
| Line 56: | Line 56: | ||
=== Coding period : Phase two (June 15th to July 13th) === | === Coding period : Phase two (June 15th to July 13th) === | ||
In this phase, I continue working on each web service separately to fix bugs and prepare for beta release of digiKam 6.0.0. Moreover, the main part of this phase is | In this phase, I continue working on each web service separately to fix bugs and prepare for beta release of digiKam 6.0.0. Moreover, the main part of this phase is factoring codes for web services. | ||
Indeed, once web services use OAuth2 as protocol | Indeed, once web services use OAuth2 as authentication protocol (implemented with O2 library), codes begin repeatable, especially in talker.cpp, where the authentication flow has been implemented so far. Moreover, future vision for web services' authentication is using QtNetworkAuth as a pure Qt solution, which enhances the portability of digiKam and facilitates development and maintainability. Therefore, code factoring is an essential step in digiKam todo list. | ||
Concretely, | Concretely, factoring is divided in two parts: authentication flow, and export tool GUI. It has to be mentioned that Gilles Caulier, one of my mentors, has prepared a common wizard for export tool. Thus, I took it as base ground to develop new export GUI. | ||
===== | ===== Centralized authentication flow ===== | ||
My solution is to define a base class for | My solution is to define a base class for talkers of all web services, which is currently handling all communication between digiKam and authorization server for access token exchange, API calls, as well as API response processing. Therefore, the idea is to group all common codes in a class, which also defines the standard authentication flow for each web service. | ||
That class contains | That class contains virtual methods to control the flow, API calls and parsing API responses, which will be reimplemented depending on API specifications if needed. | ||
[[File:auth_talkers_structure.png]] | [[File:auth_talkers_structure.png]] | ||
===== Common UI for export tool ===== | ===== Common UI for export tool ===== | ||
The solution is very similar | The solution is very similar to the case of authentication flow. I decided to create a base class containing necessary signals and slots in common between all web services. | ||
Besides, I also worked on this part at the same time with authentication flow | Besides, I also worked on this part at the same time with authentication flow fafctoring, so that I can have a GUI to test. Here are some screen shots of what I have integrated to the common wizard for export tool | ||
[[File:new_intropage.png]] | [[File:new_intropage.png]] | ||
Revision as of 15:54, 7 August 2018
digiKam: Web Services tools authentication with OAuth2
digiKam is a desktop application for photos management. digiKam provides a wide range of plugins for exporting photos to web services (e.g dropbox, flickr, facebook, etc.) alowing users to easily upload their photos to cloud storage services or share photos on social networks.
Current export tool authentication process makes it far from easy-to-use for users. In addition, authentication protocols varies much for each web service, generating many difficulties for implementation and code maintaining. Hence, this project is aimed to resolve those problems by porting authentication flow with O2 library, in order to make digiKam export tool more user-friendly and more flexible for development and maintenance.
Mentors : Maik Qualmann, Gilles Caulier
Project Goals
- Port export plugins with O2 library.
- Factor codes of new wizard for export plugins.
- Accomplish new wizard with features for photo processing before uploading.
Work report
Coding period : Phase one (May 14th to June 15th)
This phase is to port 3 digiKam web services : Google, Facebook and Smugmug to O2. It is required to change the authentication flow but still preserve main functionalities. In general, work for this part is nearly done, except some minor existant bugs to be resolved.
According to my initial plan, I must also have finished Youtube Uploader by this time. However, since porting these web services to O2 is more important and Youtube Uploader can be finished in phase two of project, when i will be working on code factorization for other web services, the whole first part of project was then spent on porting to O2.
Below is my project status.
Smugmug
Resolved :
- Authentication with OAuth2
- All methods are ported to new APIs (v2)
- Anonymous mode is removed
Google Drive
Resolved :
- Authentication with OAuth2
- Export is ported to keep compatibility with O2
Google Photo
Resolved :
- Authentication with OAuth2
- All methods are ported to Google Photo APIs (to replace current methods based on Picasa APIs)
Unresolved :
- Photos import from Google Photo are not visualized in digiKam
- Cannot export to albums not created by digiKam (lack of authorization scope from Google Photo APIs)
Resolved :
- Authentication with OAuth2
- All methods are ported to new API (v3) and kept compatibility with O2
Unresolved :
- Cannot create album by digiKam
- App review to put digiKam public mode
Coding period : Phase two (June 15th to July 13th)
In this phase, I continue working on each web service separately to fix bugs and prepare for beta release of digiKam 6.0.0. Moreover, the main part of this phase is factoring codes for web services.
Indeed, once web services use OAuth2 as authentication protocol (implemented with O2 library), codes begin repeatable, especially in talker.cpp, where the authentication flow has been implemented so far. Moreover, future vision for web services' authentication is using QtNetworkAuth as a pure Qt solution, which enhances the portability of digiKam and facilitates development and maintainability. Therefore, code factoring is an essential step in digiKam todo list.
Concretely, factoring is divided in two parts: authentication flow, and export tool GUI. It has to be mentioned that Gilles Caulier, one of my mentors, has prepared a common wizard for export tool. Thus, I took it as base ground to develop new export GUI.
Centralized authentication flow
My solution is to define a base class for talkers of all web services, which is currently handling all communication between digiKam and authorization server for access token exchange, API calls, as well as API response processing. Therefore, the idea is to group all common codes in a class, which also defines the standard authentication flow for each web service.
That class contains virtual methods to control the flow, API calls and parsing API responses, which will be reimplemented depending on API specifications if needed.
Common UI for export tool
The solution is very similar to the case of authentication flow. I decided to create a base class containing necessary signals and slots in common between all web services.
Besides, I also worked on this part at the same time with authentication flow fafctoring, so that I can have a GUI to test. Here are some screen shots of what I have integrated to the common wizard for export tool
Important Links
Proposal Link
Git dev branch
Contacts
Email: [email protected]
Github: TrungDinhT