[daisy] Better desktop integration

[Karel Vervaeke]

On Mon, 2008-05-05 at 10:44 +0200, Bruno Dumon wrote:
> On Wed, 2008-04-30 at 16:56 +0200, Karel Vervaeke wrote:
> [snip]
> > [0] http://cocoondev.org/wiki/g5/607-cd.html
> 
> Hi,
> 
> Just some things I thought of while reading through the document:
> 
> * As Marc, I think there needs to be more focus on a certain part to be
> downloaded. Maybe we need some configuration of which is the default
> part type to download for each document type.
> 
> * For (local) organisation, allow the creation of folders (= filesystem
> directories), instead of just a flat list of documents. Alternatively,
> local tagging of the documents could be used, but that seems more
> complicated and less robust.
The idea is that incoming files are placed in one directory, but it is
possible to move those files later or link other files to the list of
available parts.

> 
> * Foresee some version-handshaking between the tool and the online Daisy
> to check if they're compatible.
That is described at the bottom of the wiki page [0], unless that
approach is not sufficient?

[0] http://cocoondev.org/wiki/g5/607-cd.html

> 
> * Implementation consideration: separate the GUI and functional code so
> that creating a CLI or programmatic use is possible.
> 
> * For the local filename:
>     - there will be a need to determine the extension based on the
> mime-type. Probably this is best done by the client (based on OS info
> but overrideable by local config)
Yes, this is probably the best solution for being compatible with
multiple platforms.

>     - maybe include the document name in the file name, something like
> "Document name ~ID~branch~lang~part.pdf" (or other syntax)
I think the first part of the filename should be structured.  Where
possible, we should also use the filename as currently used in Daisy.
Unsure whether the document id/part type should end up in the filename
when posted to the wiki.  E.g. initially when we download a part with
filename "strawberry.jpg", it seems less than ideal if that image will
be stored using the filename "A document about
fruit~123-DSY~main~default~ImageData.jpg" after completing the
download/edit/upload cycle.

There should be a list of simple rules to handle filenames:
* when no filename is available, build a generic (e.g.
docId-NS~part.ext)
* When a filename is available, it should be kept like that (but
appending a serial number or prepending document/part identification to
avoid collisions)
* When the available filename does not have an extension (or the wrong
one), suggest adding the extension.

> 
> * When uploading HTML parts, apply HTML cleaner (server-side).
Good idea.  We could even notify the desktop component when a part is
not stored exactly as it was uploaded (i.e. altered by the HTML Cleaner
or some pre-save-hook).

> 
> * As Marc noted, allow more columns in the list view, I'm thinking of:
>   - are there local modfications
>   - date of last modification
>   - is there a lock on the doc
>   - what version is downloaded, what is last version on repo
>   - data size
> 
Agreed

Thanks for the suggestions,
Karel