On Wed, Mar 31, 2010 at 09:30, Asiri Rathnayake
<asiri.rathnayake(a)gmail.com> wrote:
Hello Devs,
I committed an office-preview module in sandbox (
http://svn.xwiki.org/svnroot/xwiki/contrib/sandbox/xwiki-officepreview/)
about a month or two ago.
The purpose of this module is to enable previewing of office attachments
(word, spreadsheets, presentations) using the office-importer module. This
module was developed for a demonstration purpose and needless to say it was
cooked up as fast as possible without much attention to technical aspects.
We've planned to integrate this module into platform and therefore need to
clear out those technical issues. Our initial plan was to make this module
available in 2.3 final release, but I doubt if I would have enough time to
spend on purifying the code before it can be integrated. In any case I will
list the technical issues we have with current code and propose some
solutions so that we can come to an agreement about the design:
1. Each office-preview consists of an XDOM and a bunch of temporary files
corresponding to images embedded inside the original office document.
Currently these temporary files are stored inside the "charts" directory
used by the charting plugin. I'm not sure if using "charts" directory and
the "charting" action is a good idea, may be we should introduce the
"tempresource" action before integrating this code.
+1 for make temporary resource generic.
2. An office-preview needs to be aware of attachment version (if a new
version of an attachment is uploaded, preview must change). Also, when
building the office preview, urls to temporary files (images) must be
generated.
2.1 Currently DocumentAccessBridge does not provide an API to query the
attachment version.
2.2 Generating urls to temporary files inside "charts" directory cannot be
done via any component api.
Because of above two reasons, office-preview module currently depends on
xwiki-core module which is a bad practice for newer modules. We can deal
with this issue by adding new methods to DAB (not good) or by having a
component interface inside xwiki-officepreview module and it's
implementation in xwiki-core module. I'm not sure if any of these solutions
is perfect.
I prefer the second solution and the one we commonly decided to do: a
separated module depending on xwiki-core.
3. Each generated office-preview is cached. When a cache entry is disposed,
all the temporary files associated with that preview is deleted
(DisposableCacheValue). However, I noticed that
DisposableCacheValue::dispose() is not invoked when XE shuts down. We could
fix this by adding an event listener to listen for XE shutdown events and
calling DisposableCacheValue::dispose() manually.
Actually the issue is that you don't do it the right way IMO: in java
you can "tag" a file as real temporary files, i.e. that is supposed to
be deleted when java stops.
See File#deleteOnExit
4. A requested feature (by ludovic) is to cache the whole office-preview
(i.e. XDOM + tempfiles) on the disk, this way previews will even survive XE
restarts. This is something we need to agree on.
I'm not sure what this "feature" brings. Is it that long to generate
the temporary file and XDOM the first time it's used before caching it
?
5. Previewing office presentations (ppt) poses a lot of problems. A
presentation import (as in officeimporter) consists of a .zip archive with
image slides and html slides (text version) and the XDOM simply hosts a
piece of html that reads slides from this .zip attachment. This idea does
not jump into office-preview module very well and therefore we dumped html
slides and kept image slides only for previewing. There are few hacks I did
to implement previewing presentations but I'll talk about them in a separate
email.
I would be very glad if you can comment on first 4 points I've mentioned.
Once we have reached an agreement on these points, I'll make necessary
changes and integrate the code in our main source tree.
Thanks.
- Asiri
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne