Desktop integration

A lot of useful feedback on this document can be found in this mailing list thread: http://thread.gmane.org/gmane.comp.java.daisy.general/7617
The initial idea was to merge the information of this thread with this document, but it would not be productive to do so.  Please view the thread for a complete view of the current state.

Introduction

Bottom line: allow download/upload cycles but provide a more fluid collaboration with desktop authoring tools. Primary scope: Office, more specifically Powerpoint. Ultimately, it should be possible to download, edit and update/re-save a Powerpoint document stored in Daisy in one single fluid workflow.

(Same goes for images, other office documents, ...)

Idea

• A desktop component is installed on the user's desktop.
• This application manages a list of documents.  For each document, the necessary information (id, name, version, parts, daisy url) is stored.  The parts are stored on the filesystem.
• A new link in the 'Actions' menu, below 'edit', called 'edit using desktop application' (should be shorter)
• When the link is clicked, the document is added to the desktop component's list.
• Desktop component functionality:
• Edit => starts desktop application for editing a part
• Upload => sends changed parts to the server
• Update => updates the document cache (obtaining data via the daisy wiki)
• Sync => combination of upload and update
• Remove => remove the document from the list (possibly discarding changes)

Desktop component installation / Depoyment

Component installed through JWS.

Component can be started

• when operating system / window manager starts (configured in the component)
• when user clicks 'edit using desktop application'
• anytime (double click desktop icon)

Wireframes

Click to enlarge

Remarks / Ideas:

• Sync should be split up into upload / download and sync, so user can choose which action is performed
• At any time when conflicts are detected  (using version nr, but ideally based which parts have changed) the user is notified and appropriate suggestions are made
• Same for Sync all.
• Some faceted browser-like functionality to allow users to easily find documents in the document cache (a simple flat list is not enough, would make it too difficult to find documents when performing mass edits).
• Component should handle cases where user has no read last access and/or no write access.
• Missing in wireframe: menu bar or other means to get to configuration part.
• Configuration part should be able to store multiple daisy accounts:
• Documents may come from multiple daisy instances
• User may have multiple accounts on a single daisy instance.
• Idea: when 'edit in desktop app' is clicked, the component checks whether it knows the credentials for the current logged in user in that Daisy instance.  (One step further: Component does not necessarily need daisy account info: it can reuse HTTP Session id - should only require password when http session is lost).
• Missing in wireframe: Should there be an option to change the metadata (e.g. attach another user to a document or even change the  daisy instance URL (when it moved, e.g.). 
• (Probably does not happen often enough to take into account:) When Daisy wiki is moved to another URL component will not be able to know new location - it should follow http redirects: this way, wiki administrators can set up redirects and be sure that desktop components and their users will be happy.
• Other ways to add documents to cache:
• After fulltext search (?): may be useful for PDFs
• After querysearch: useful for various document types
• From document basket.
• Mass edits:
• When users goes to the part cache on the filesystem, he should be able open files immediately from there, hence it would be nice if the filenames are constructed to be readable (e.g. docId-NS@branch#language#version#partname(or number).extension) (where the extension is taken from the current document filename as stored in the parts table in the repository database)
• Clicking 'edit using desktop application' should immediately add the document (if not already there) to the desktop application and show and the desktop should pop up with the correct document selected.
• Probably the component immediately open the dropdown / popup 'Select which part you want to edit'.

Unsolved / TBD / Suggestions welcome

'edit using desktop application' - URIs ?

Extension for associated filename(s): .ddc (daisy desktop component), alternatives welcome (such as .ddi = Daisy Desktop Integration, .ddx (sounds fancy), ...
Mimetype: application/daisy-desktop-launcher, alternatives welcome

Desired features:

• URI should identify the associated document
• URI should have extension that can be registered in windows (so it is opened with the desktop component)
• We should also be able to add multiple documents (fulltext / document basket / ...).
• In case of document basket, the URI can not identify which documents are involved, the file contents will be generated once.
• In case of document search results, the URI can contain the query in a queryparameter.

Suggestions:

URIs ending with .ddc extension

http://.../site/999-DSY/123-DSY.ddc (+ mimetype)
http://.../site/search.ddc?query=....&otherparams
http://.../site/docBasket.ddc

• pro: easy to implement if we can assume the desktop component is already installed
• con: if the desktop component is not installed, Windows will typically try to look up the correct application (and it will probably fail unless the mimetype application/daisy-desktop-launcher or is registered somewhere in Redmond HQ.

Dedicated "protocol" (skip this idea, it's worthless)

ddc://.../site/123-DSY.ddc
...

• Should be investigated if it can be useful to use a 'special' protocol.  E.g. ddc://.../site/123-DSY.  It could be interesting to investigate if we can register the ddc protocol under various environments (browser / operating system).  OTOH, I don't know if there is a good argument for doing this, probably not.

URIs ending with .jws (java web start) extension

http://.../site/ddc.jws?documentId=123-DSY&branch=... or http://.../site/123-DSY/ddc.jws?branch=...
http://.../site/search/ddc.jws?query=...
http://.../site/docBasket/ddc.jws

• pro: In this approach it is not necessary that the desktop component is already installed when a user first uses the 'edit using desktop application'
• con: Probably some overhead calling JWS each time the link is started (needs to be investigated)
• For ddc.jws?query=... is it possible to pass the query parameters to the jws application being started

Filetypes / contents

When opening a single document, the url probably contains all the info necessary to identify the document.  The file should still contain information about the document and associated daisy instance URL, so the desktop component knows what to do without needing an additional call to the wiki.

Same goes when opening a 'multidocument' url (search / document basket): There should be enough info in the file so no new calls are required.
This way, people can not only send URL's to eachother, but also .ddc files (this seems to be a great argument in favor of .ddc when evaluating .ddc vs .jws, the only drawback remains the requirement to install the desktopcomponent before clicking the link)

Other features (not related to document editing)

The desktop component should be able to check if it is still up to date (so it can warn the user about updates)

The .ddc files should contain a version number so the desktop component knows if it can handle the .ddc file.
(This version number should not be the daisy version number - this way the component does not need to be upgraded with every daisy release, but only when the ddc filetype changes)

Fields