73

EDIT: Create new Kio services instead?

This idea is to make certain Akonadi resources new website-based Kioslaves available to Dolphin and other applications capable of browsing the file-system.

The reasoning is that Dolphin, though a file manager, doesn't easily let you manage ALL your files EVERYWHERE. You could have hundreds of images on Flickr and Facebook, videos in Youtube and Vimeo, documents in Google Docs, other files in Dropbox or Ubuntu One storage (or other online storage solutions) and so on.

This idea is to be able to manage all these files from within Dolphin (and GWenview in the case of images) from special Akonadi Kio folders. You can upload, download and remove e.g. Flickr photos simply by changing them in the Flickr folder. Using Flickr as a further example, you could export tags, descriptions and people in photos to Nepomuk and be able to search them without ever noticing that they're not actually on your computer but on Flickr. Of course, changing these attributes would change them on the Flickr website as well. Other changes could include a change to the, "permissions" tab in right-click --> Properties, with options to make photos private, viewable by friends or public instead.

More interesting, though, is the kind of work-flow that could be introduced as a result: a friend could send you a picture and, instead of saving it locally, you could, "save" it in the Facebook Akonadi Kio folder and have it posted on Facebook immediately.

Looks like a really KDE SC 4 idea, but hard to do.

This is properly handled by KIO slaves, not by Akonadi. Please update the idea accordingly.

@Gallaecio
It would not be hard to do.
Implement a KIO-Slave for Flickr, FreeDesktop or whatever, that's it...

It may be hard but it would really increase web integration and once the 1st one is done others could use the same frame-work to make short work of the next.

The main idea somehow reminds me to WinFS, which probably disappeared because of serious performance issues.

Using KIO-Slaves looks better, but again within time you should have to deal with format/api changes, and that is a problem in a wide range scenario.

In the end I think this should be handled by the web browser, and keep dolphin doing the job that's doing now.

Regards

Changed idea title to Kio-powered instead of Akonadi-powered.

Mamonetti wrote:Using KIO-Slaves looks better, but again within time you should have to deal with format/api changes, and that is a problem in a wide range scenario.

Both plasma dataengines and kipi plugins have this problem as well, yet those are both used extensively.

You will need to write a new KIO for EACH of these services.

With that it mind - pick one and I'll certainly help someone write something. (not sure I have time to do it all). Think /why/ you'd want it, and describe how you'd map everything to files/folders.

Look at audiocd:/ to get some example of what can be done.

I've written KIOs after an idea on brainstorm once before (http://kde-apps.org/content/show.php/Pa ... ent=106694) I can do it again

david_edmundson wrote:You will need to write a new KIO for EACH of these services.

What you would probably end up doing is making a generic web-service parsing API for KIO (if there isn't one already), then making specific implementations for each website. They will probably share a lot of code, you would most likely end up just needing some sort of translation layer that would convert their API calls into the KIO web service API calls. The KIPI plugins could probably be used to figure out the APIs of the various websites. I would think this would benefit KIPI in turn as well since it would no longer need its own implementation.

The intention of my comment was trying to get the original poster to choose just one thing and help towards designing it.

It's all very well for people to come up with these massive broad suggestions, it's another to turn it into something real. I'd like to see more of that.

The things I'd be looking for are:
- A description of what you'd like the KIO to do and most importantly why it will benefit lots of users

- link to relevant website's API documentation

- a list of what 'folders' you'd expect to see, and ideally link it back to the website's API functions

- a list of the 'files' you'd see in these folders, and list how you'd use the websites API to find out name, size, mimetype, and get the content.

This needs doing however you wrote the underlying code, and it doesn't require any coding experience.

Side note: A KIO for Ubuntu One has already been started by the kubuntu people.

I don't think it would be easy to do with Facebook, with their very closed approach, but I also think the guys at KIPI figured out a way to get images from and put images on Facebook. I'll focus instead on Flickr, since they have an extensive API on uploading and downloading images (http://www.flickr.com/services/api/) which is available free for non-commercial use and also promotes libre licensing (Creative Commons).

I would expect the folder structure to match Sets on the website. I don't think that all images should be shown in to the root KIO folder, though, and should instead belong in another folder, "All Images" to reduce clutter and loading overhead. Tags, descriptions and people would be exported to Nepomuk to make them searchable (and perhaps even to link Flickr people with Akonadi addressbook contacts?). Images can be present in several sets, in which case they should simply appear in both folders.

Have I missed anything?

EDIT: yes, I have -- Yahoo also have an open-source desktop client called, "Flickr Uploadr".

Solid start.

So we have the following designed:

When I visit
flickr:/idOfASet/ in dolphin

I see all of the images in that set as though I'm looking at a folder of images (using flickr.photosets.getPhotos), each file in that folder is called


flickr:/idOfASet/idOfAPhoto.jpeg


this contains the full size image of said photo (using flickr.photos.getSizes).

Pushing forward:

What about when someone visits just plain flickr:/ showing them a list of every Set on flickr would be a bit much.

I could force the user to give a flickr username/password and it could list sets that belong to them.

I prefer to try not to get too carried away with exciting ideas and try and get something real started first.

A bridge isn't built all at once.

P.S. Yes, this was intended for managing a single flickr user's photos, so that's what I was hoping for.

I nearly have a read only draft implementation complete. It lists photosets, lists photos in there - and inside that shows the photos.

Listing is fast, but it takes an age to load thumbnails (because it's actually downloading the entire image).

I don't think there's any way around that. In terms of the KIO it has no idea (and shouldn't really) what is doing the downloading and why.

Madman:
I need a square flickr icon. Want to find/make one?