Stephen Connolly wrote: > I am toying with having the format be xml.gz rather than xml
> OTOH transport GZ should be easy and makes the file easier for users > to > inspect > > Thought? If you mean by "transport GZ", serving the XML with "Content-Encoding: gzip" by the repository manager, than that is IMHO the way to go, as it allows to transparently transition to another (better) compression scheme later (e.g., Content-Encoding: br). The experience with Eclipse p2 update sites, whose (content|artifacts).xml can also be served as .jar and nowadays also as .xml.xz shows that is cumbersome to generate the same metadata in different compression formats for newer and legacy clients. But this experience also shows that the ability to transition to a better compression format is something that is indeed desirable, as newer formats may offer real-world benefits (~50% savings in download size). See [1] for details. Just my 2 cents, Andreas [1] <https://bugs.eclipse.org/bugs/show_bug.cgi?id=464614>
signature.asc
Description: OpenPGP digital signature
