On 06/06/2017 06:17 PM, Jeff Hooker wrote:
I’m about to start talking with Bluestream about upgrading their
integration with XMLmind, but before I do I have a question of a
technical nature about how XMLmind could potentially interact with the
Bluestream XDocs database.
The current integration with XDocs involves XMLmind needing all of its
working files (and all of the working files’ dependencies) in a local
cache before it is capable of opening and working with the content. This
puts XMLmind at a significant performance disadvantage, since it means
that before a writer in Japan can edit a ditamap, every file connected
to the ditamap must be downloaded to the local cache. We’ve done a lot
of work with cache optimization, but ultimately the result is that a lot
of content that is not actually needed being downloaded to the user’s
machine as a real performance cost.
First of all, I would strongly recommend that you ask Bluestream
developers why there are performance issues with XXE.
If their answer to this first question is "because XXE needs all of its
working files in a local cache before it is capable of opening and
working with the content", then the next question would be "why that
given the fact that XXE can be used to access/open/edit all kinds of
remote files? XXE is URL-based, not file-based".
Bluestream’s Oxygen integration is structured so that only checked out
content is actually local, and all other content is linked back to the
XDocs server. This is the model I would like them to pursue for the next
XXE integration, but I would like to know if the XXE API can even
accommodate that approach before I push for it. Has the XXE API been
built to accommodate this model?
It's difficult to give you an authoritative answer.
Let's say that thanks to the Virtual Drive plug-in developed by
Bluestream, XXE sees all the files stored in the XDocs database as
having "xdocs://foo/bar/gee" URLs.
XXE does not care about where and how a file having a
"xdocs://foo/bar/gee" URL is actually stored.
This abstraction should allow third-party developers to implement all
kinds of file caching strategy.
It seems that Bluestream developers need to rewrite their Virtual Drive
plug-in in order to implement a file caching strategy where only checked
out content is actually local (if and only if this is the *real* *cause*
of the performance issues).
Note that if Bluestream developers make *reasonable*, *generic*,
requests about enhancing the Virtual Drive plug-in API, we'll almost
certainly implement these requests.
Reference:
the Virtual Drive plug-in API,
http://www.xmlmind.com/xmleditor/_distrib/doc/api/com/xmlmind/xmleditapp/vdrive/package-summary.html
--
XMLmind XML Editor Support List
xmleditor-support@xmlmind.com
http://www.xmlmind.com/mailman/listinfo/xmleditor-support
