[daisy] Better desktop integration

[Marc Portier]

Karel Vervaeke wrote:
> We are planning to make things much better by creating a desktop
> component that will even make it unnecesary to go to the HTML document
> editor.
> 
> [0] http://cocoondev.org/wiki/g5/607-cd.html
> 
> Please post your remarks to the list, I will gather your input and merge
> it with the document later.

A lot of thoughts I had when reading the document, in no particular order:


* Main observation: daisy works with *documents*, but these external 
editors will all work on *files* that fit into single parts of daisy. 
 From that observation I more and more got the feeling that this tool 
should focus on files/parts first and only for the interested and for 
background daisy communication know (and show) detailed info about the 
actual daisy-documents.

The most obvious effect of this would be that the gui proposal would 
change to  not list daisy-documents, but rather files (or daisy-parts). 
And probably thus by 'filename' rather then by document-name (or id) + 
partname.

For most 'simple' documents the relation is 1-1 so doesn't make a big 
difference?

* Leading to my name/abbreviation(extension) proposal: dpm for daisy (or 
desktop) part manager

* Leading to my menu-integration proposal
   - it's getting crowded already but I think this deserves a separate 
menu entry:
     - Desktop Part Manager (or something shorter)
         - Install (link to docs or jws directly)
         ------------
         - Manage All Parts (unlikely IMHO)
         ------------
         - AttachmentPart
         - ImageDataPart


* Additionally some (all?) part-editors (in html) could easily provide 
an obvious button to "manage this part through a desktop editor tool"
   - this probably calls for an extra property of part's (or 
part-document-associations) that indicates of external editor management 
should be offered or not (something the xsl will eventually pick up 
probably)

* If possible the desktop component should have the possibility to 
notify the user via the systray. + We should list the kind of 
notifications that could be of interest. (If not via the systray, at 
least via the component itself)

* In the list of "Desktop component fucntionality" I was missing two 
actions:

   - "Overwrite" which would allow to just copy over a local file over 
the one that is in the local dpm-cache

   - "Revert" which should allow to discard all local changes and go 
back to the version at last checkout-time (by keeping a .svn like 
original copy so it is available off-line?)

* and if I've read the discussion between Jorg and Lou correctly, a 
third additional operation could be:
   - "Link To File" which would allow telling the system that the 
part-file itself is not internally in the "local cache" but rather 
pointing to another file-path

* Note that drag-drop might trigger similar effects:
   - drag-drop-in could be 'overwrite'
   - drag-drop-out could be 'link to'
* And in the same area: double-click should equal the mentioned 'edit'

* When the user chooses (in his browser) to manage a part from the 
desktop a so called dpm launcher file should be sent in the reply
   - extension and mime-type should be associated to launch the desktop 
component
   - file should probably not hold the contents (binary octet stream) 
but only all required metadata (xml or json format) to support all 
required management operations

* The wiki-document should be extended with a more detailed description of
   - the contents and layout of the
	- dpm launcher file
   	- dpm local cache directory
   - the extra cocoon supported uri's that will handle the pass-through 
part operations on the repository (cause I think we should not just call 
the repo directly)

* gui should display appropriate file-preview icons, if possible those 
associated to the part's mime-type/extension as per the host's OS settings?

* With respect to the support for multiple daisy instances:
   - I'm not sure, but I think we can have one installation of the 
dpm-desktop component per daisy instance connected to?
   - Main argumentation for that: having one jws installation per 
daisy-installation/server means they can independently follow up on the 
version upgrades in the future (jws update)
   - There is probably a very limited set of users that get to work with 
more the one daisy instance in this way?
   - The JWS installation can easily (and clearly) hold the name of the 
daisy installment one works with...

* More on the support for "configuration" in the gui of the desktop 
component: Specially stuff like user/password can probably be 
managed/stored in the background? I would hope we can keep this 
component as lightweight as possible.

* In contrast with that: I like the idea of the facet-assisted searching 
in large document-sets. We should however clearly list on which facets 
this browsing would occur (mimetype, extension, date, document type, 
document owner, ...) In the end sortable and configurable columns might 
be good enough.  Big question is what size of local cached documents do 
people expect to be managing at any given time in this way? (personal 
guess would be around 20-25)

* I like the idea of reusing the current logged in session from the 
browser. We'll have to be weary of session hijacking though. (Even if 
this is not in the 'criminal area' e.g. dpm launcher files being 
forwarded by email to some colleague)

*As for the listed URI's
   - I would keep the jws URI's strictly for GETting the web-start file 
to trigger the local installation.
   - Same for the dpm-launcher file
   - Next to that there should be a set of pass-through REST-like part 
mangenemet URI's to actually get/update the part contents.

* The wiki-document can use a glossary since it introduces some new 
nomenclature in daisy land.  Local Document Cache, Desktop Component, 
DPM Launcher File,...

all for now,
regards,

-marc=