Questions about zipped customizations...

[JasonBuss]

We are currently using 5.3 M040, and we are testing 5.4 M100. I have been reading up on zipped customizations, and it shows some promise (we do have an offshore team, and the network is ALWAYS an issue). I was wondering if others have been using these custom zips, because I did have a couple of questions.

First, we still use catalog files to resolve all of our 150K images using PUBLIC IDs. If a catalog file in the zipped customization points to this other catalog file, can it resolve it correctly (and not try to cache all of these graphic entities)?

I guess that leads into my next question, if your APTCUSTOM is pointing on a web server, which is downloaded and cached, can it be used to reference a file external to the zip file?

We use a FOSI entity file to define specific revision dates for each revision of each publication (please don't ask). It's basically a huge list of <att> rules. As would be expected, this list gets updated once or twice a week. If it's included in the zip, it will have to be zipped and updated on the web server, which would cause it to download the updated zip anyway, right? If the zip file includes a FOSI that references this as an external entity outside of the zipped structure, can this work?

I'm just rattling out loud at the moment. There was half a page of documentation on this subject through all of the Arbortext documentation. And it repeated the same half-page in three documents.

Thanks,

-Jason A. Buss

[ClayHelberg]

Hi Jason--



You'll have to do some testing to be sure, but I think you should be
able to refer to files outside the zipped customizations by using
absolute paths/URLs. So, for example, your main catalog file inside the
zipped customization could reference a graphics catalog file on a server
somewhere else.



Of course, in that case, you may be stuck with the same network latency
issues that you are trying to solve using zipped customizations in the
first place. You may have to do some experimentation to determine which
parts of the customization can be hosted on the server without affecting
performance, and which need to be in the zipped package to avoid
bottlenecks.



Another way to think about the trade-off is this: putting everything in
the zip may mean a longer startup time, but after that everything should
be pretty fast. OTOH, having some of the more frequently-updated files
on a server outside the zip will probably mean shorter startup times
(most of the time), but then some operations during editing may be
affected by the network traffic of retrieving those remote files.



--Clay

[bibach]

You might optimize the trade-off by using multiple zip files, just as
you can have multiple custom directories. Most of the files would go
in one zip archive, while the more frequently updated might go in one
or more other archives. Public identifiers would allow clean
references between files in different archives.

All theoretical, of course. Let us know how it works in practice. 😉

-Brandon 🙂