Bug 221704 - FACTORING : create a common interface to perform uploads/downloads with remote web services
Summary: FACTORING : create a common interface to perform uploads/downloads with remot...
Status: REPORTED
Alias: None
Product: digikam
Classification: Applications
Component: Plugin-Generic-WishForNewTools (show other bugs)
Version: unspecified
Platform: Ubuntu Unspecified
: NOR wishlist
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
: 96666 (view as bug list)
Depends on:
Blocks:
 
Reported: 2010-01-07 20:29 UTC by hadmut
Modified: 2022-01-10 20:51 UTC (History)
6 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description hadmut 2010-01-07 20:29:55 UTC
Version:           1.0.0 (using KDE 4.3.2)
Installed from:    Ubuntu Packages

Hi, 

digikam comes with a list of supported websites for uploads, but there are lots of portals and stock image websites not yet supported. 

Would be nice to have a general interface for uploading, where you can e.g. just plugin a self-written shell/perl/ruby/... script for automated upload. 

regards
Comment 1 Johannes Wienke 2010-01-08 10:50:03 UTC
Gilles. maybe this would also be a candidate for the planned integration of these services directly into digikam, maybe via akonadi?
Comment 2 caulier.gilles 2010-01-08 10:56:34 UTC
Johannes,

...and link digiKam to Another big KDE part as Akonadi, where we have no feedback about Mac and windows ports ? What's about stability ?

Hum... sound like a big puzzle. If something must be done in this way i feel better a new plugin. But it just my viewpoint.

Also, we have others problem to solve in priority, as to merge ranches to trunk after 1.1, and complete Qt4 port definitively...

Comments are welcome here...

Gilles
Comment 3 Johannes Wienke 2010-01-08 12:17:02 UTC
Doesn't have to bee Akonadi. We could also provide a general export interface on our own and unify the export plugins. I'd also like to see a better integration of digikam keywords etc. for the plugins. So that's definitely something that cannot be done in kipi-plugins. And it's also something not for the next release. ;)
Comment 4 caulier.gilles 2011-12-22 11:14:25 UTC
*** Bug 96666 has been marked as a duplicate of this bug. ***
Comment 5 caulier.gilles 2018-11-03 11:02:22 UTC
WARNING : with digiKam 6.0.0 and later, we will not support kipi interface anymore. All tools are now located in digiKam core as well for a plan to provide a more power-full integration with Batch Queue Manager and to be able to export a workflow on a web-service.

All export tools are now available everywhere : album view, Image editor, Light table, and Showfoto. Previously, only album view from digiKam core was able to deal with export tools through libkipi.

All export tools are now located here :

https://cgit.kde.org/digikam.git/tree/core/utilities/assistants/webservices

All export tools use now a dedicated interface to communicate with the application : 

- digiKam (database) : 

https://cgit.kde.org/digikam.git/tree/core/libs/database/utils/ifaces/dbinfoiface.h

- Showfoto (files metadata) : 

https://cgit.kde.org/digikam.git/tree/core/utilities/assistants/common/dmetainfoiface.h


There is not direct use of digiKam database for compatibility with Showfoto.

We plan later to provide a dynamic loading of export tools using a plugins mechanism. This will reduce overloading of the internal core libraries. A dedicated devel branch have been created for that, but it's not yet complete:

https://cgit.kde.org/digikam.git/tree/?h=development/dplugins

But take a care, digiKam export tools as plugins will not be shared with another external application. API will still private and only shared between Showfoto and digiKam core. The experience with libkipi was bad and complex to maintain/extend in time.

Gilles Caulier