Skip to content

[Suggestion] Analyse & decide on src/dropbox/qt-json #111

Description

@Olf0

I discovered that the files src/dropbox/qt-json/json.cpp and src/dropbox/qt-json/json.h are not referenced in their corresponding sections (categories SOURCES and HEADERS) of filecase.pro, see PR #105 for testing which unreferenced files are actually usable.
I then documented these (and other) findings "inline" in filecase.pro via PR #107.

Trying to chase down the origin of the content in the directory src/dropbox/qt-json/, I found:

  1. lycis' QtDropbox
    Provides easy access to the historic Dropbox-API v1 (REST-based) for Qt 4 and 5.


    This project has been unmaintained for 10 years.
  2. osoftteam's dropboxQt
    Provides easy access to the Dropbox-API v2 (i.e. HTTPS-based) for Qt 5 and 6 (AFAIU, the latter in beta-status).


    This project has been unmaintained for 7 years.
  3. Using Dropbox's API directly
    Dropbox provides good documentation, examples and a developer forum for their API v2 (HTTPS-based).

    This has some appeal, because it seems to be the only well maintained way to access Dropbox from Qt. Furthermore, the examples ("pre-built components") are in JavaScript, and as the Dropbox-API v2 is HTTPS-based, it should be easily usable in QML.

    Though the current source code structure and architecture of FileCase suggests only the use of C++ in the "back-end" (i.e. non-UI components), this should pose rather small hurdle.

  4. Dropbox's use of OAuth2
    … seems to be slightly tricky.

    But there is some support for addressing this, e.g.:


Despite the age of osoftteam's dropboxQt and chilarai's Qt-Dropbox-oauth2, this actually serves SailfishOS in its current state (still providing only Qt 5.6) well. More modern projects and programming examples for Qt 6 are likely much harder to adapt, and projects using C++ 17 features may not even compile. I also would like to maintain FileCase's compatibility to older SailfishOS releases (and hence also their corresponding, historic Sailfish-SDKs) as long as that does no require significant efforts.
Thus dropboxQt and / or Qt-Dropbox-oauth2 still might be a good choice despite being unmaintained, if they minimise the efforts for an implementation significantly compared to a direct use of Dropbox-API v2.

After all this research, I still have no idea where the qt-json component originates from, and actually do not really care any longer.

Ultimately I "compile-tested" src/dropbox/qt-json/json.* by referencing them in their corresponding sections (categories SOURCES and HEADERS) of filecase.pro via PR #109: The result shows, that it does not compile.

Because qt-json is definitely unused and useless in its current state, I updated my inline-comments in filecase.pro accordingly by PR #114.

P.S.: Contributes to issue #48.

Metadata

Metadata

Assignees

No one assigned

    Labels

    feature requestfeature requests, suggestions, ideas etc.

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions