[xwiki-devs] About integrating office-preview module in platform
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. 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. 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. 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. 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
On Wed, Mar 31, 2010 at 09:30, Asiri Rathnayake <[email protected]> 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 [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
Hi,
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
Hmmm, that didn't come to my mind. Thanks :)
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 ?
Yes. Invoking openoffice, creating XDOM + temporary files can take some time specially if the office attachment is quite large. However, we can also consider using some javascript icing to make the user wait (first time only) instead. - Asiri
participants (2)
-
Asiri Rathnayake -
Thomas Mortagne