Hello Hussein, I've spoken with Bluestream now, and according to them the main issue they had with the Virtual Drive API previously was that it lacked a means of getting the title of a topic remotely, so they had to download the resource to the local cache in order to populate title information. Has this changed (assuming it was correct in the first place)?
If so, I have about $20,000USD in budget for upgrading the XXE addon which I will use for performance improvements rather than usability improvements. Thanks, Jeff. -----Original Message----- From: Hussein Shafie [mailto:huss...@xmlmind.com] Sent: Wednesday, June 7, 2017 7:58 AM To: Jeff Hooker <jeff.hoo...@microsemi.com> Cc: 'xmleditor-support@xmlmind.com' <xmleditor-support@xmlmind.com> Subject: Re: [XXE] Using XMLmind with a remote XML CMS EXTERNAL EMAIL 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
