On 01/04/2019 14:38, Langer, Christoph wrote:
:
Hm, when I was looking at it initially, I was also wondering if it would be cleaner either have a
default ZipFileAttributeView/ZipFileAttributes implementation that doesn't extend Posix or an
"Enhanced" ZipFileAttributeView/ZipFileAttributes that would extend Posix. But I saw in
the implementation of ZipFileAttributeView::get that this is already the "gate" where the
requester would get the ZipFileAttributeView implementation with the requested behavior set. So I
was hoping that it'd be fine to handle the Posix extension this way. Do you really think that
wouldn't work?
Alternatively, I could explore a different class hierarchy for
ZipFileAttributeView/ZipFileAttributes...
The issue with ZipFileAttributeView extending PosixFileAttributeView is
that it change the attributes defined by the latter to optional, e.g.
try readAttributes "zip:*" when enablePosixFileAttributes is enabled and
disabled. I think it would be simpler, as least for the specification,
to separate them.
:
As regards next steps then I think we need to agree the spec changes, as
in the the javadoc in module-info.java. Once we have the spec agreed
then the CSR can be updated and finalized. The code review can be done
in parallel of course. I think Lance is going to help review the changes.
Ok, I guess this eventually boils down to agree upon the right way of doing the
"permissions" attribute or is there something more related to the spec?
We'll need to do a bit of wordsmithing too. For example, the current
draft has "It is possible to query a Path object .." when it should be
saying "It is possible to query a file in a Zip file system ...". This
is all straight-forward, I think the main things now are to get
agreement on the relationship between the different sets of attributes
and the name of the permissions that the zip view supports.
-Alan
