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 _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
