breaking change wishlist

[CosmicHorrorDev]

• update outdated dependencies present in the public api

  • ownable@0.6 -> ownable@1 (yay stable release 🎉)
  • winnow@0.5 -> winnow@1 (yay stable release 🎉)

• drop deprecated rc-zip/corpus feature

• unused feature pruning

  • rc-zip/tracing-subscriber
  • rc-zip-sync/positioned-io The rc-zip-sync crate has a positioned-io feature, but actually doesn't support it #93

• change HasCursor::Cursor from &[u8] to std::io::Cursor<&[u8]> for infallible offsets?

  • re: entry reader oob fix: bounds check before seeking from archive fsm #124 (comment)

• some kind of change to accommodate info-zip old unix extra fields re fix(rc-zip): temporarily ignore info-zip old unix extra field #130

  • maybe something like vv (although maybe something separate from ExtraUnixField entirely to avoid having a lifetime from an optional field 🤔)

    pub struct ExtraUnixField<'a> {
        pub atime: u32,
        pub mtime: u32,
        pub uid_gid: Option<UidGid>,
        pub data: Option<Cow<'a, [u8]>>,
    }
    
    pub struct UidGid {
        pub uid: u16,
        pub gid: u16,
    }

• shrink rc_zip::Entry size shrinking Entry size #153

• standard naming convention

  • rc_zip::Error::IO(_) -> ::Io(_)
  • rc_zip::parse::Msdos* -> ::MsDos*

[fasterthanlime]

Do you think we're nearing time for 6.0.0 ? We can do that for sure. — take a ~week to make these changes (you code I review — or let me know if you actually need me to step in and make some of those changes myself) then publish 6.0.0?

[CosmicHorrorDev]

i dont think its necessarily nearing time, but im trying to keep track of potential breaking changes for now. id be up for doing the coding, but im in no rush (and a bit busy with moving atm. maybe in a couple of months)

[george-steel]

Something that could make rc-zip-sync significantly easier to use would be allowing ArchiveHandle to own its underlying reader, allowing it to be returned from functions after creation without the need for yoke. Borrowed handles could still be supported by implementing HasCursor and friends on the reference types. This would also allow the creation of an ArchiveHandle from &'a [u8] instead of requiring &'a &'a [u8] as the current version does

[CosmicHorrorDev]

i was playing around with that a bit (although i think its even more important in async code which struggles with passing around non-'static data. ref the first part of this comment #146 (comment) and also #147). the main downside im currently bumping into is that it would require one of:

• using Arc<Vec<u8>> and Arc<[u8]> as the fundamental types which would require a lot of extra allocations
• somehow splitting the api where there are owned archive/entry handles along with reference based handles that can be crated from the owned variants

[CosmicHorrorDev]

you can emulate an ArchiveHandle that owns its file with the method in #147 btw. granted you still have references to it with the entry handles

---

also also now that you mention the &&[u8] stuff which is from &[u8] being the fundamental type and the archive holds a reference to it. i dont think anything should be stopping us from using [u8] instead that way it holds a &[u8] 🤔

[george-steel]

@CosmicHorrorDev Implementing both owned and referenced ArchiveHandles did not require splitting the API as this information could be pushed into the type paremeter F. For existing usage, the old ArchiveHandle<'a, F> now becomes ArchiveHandle<&'a F>, with a 'static F now producing a 'static ArchiveHandle.

I currently have this implemented in rc-zip-sync as #157 and it looks like I might be able to do this to rc-zip-tokio as well.

[CosmicHorrorDev]

i saw, those changes look great!

the issue when it comes to rc-zip-tokio is that the entry handles hold a reference to the archive handle that they come from which becomes a problem the second you try to pass it to another future (non-'static lifetimes and spawn bounds). i dont think that can be fixed in the same way without allocating for each EntryHandle you make

[CosmicHorrorDev]

you can still absolutely make rc-zip-tokio's ArchiveHandle own the underlying file which would be great though! ideally the -sync and -tokio APIs mirror each other where able

[george-steel]

In rc-zip-tokio, an EntryHandle doesn't have any async methods, only EntryReader does. If we add the ability for the EntryReader to clone the underlying store (which could be an Arc) and become 'static, this could simplify lifetimes without any extra allocations.

In terms of other breaking changes, Why do we have ReadZipWithLength as a trait? It might be simpler just to make it a top-level function with the HasCursor bound on its parameter. If we added a HasFilesize trait, it would also be possible to make read_zip a function (with a bound of HasCursor + HasFilesize + Sized, which could simplify the implementation hierarchy a lot.

[CosmicHorrorDev]

If we add the ability for the EntryReader to clone the underlying store (which could be an Arc)

oh yeah that should work as long as all the types are cheaply cloneable (which i think would just means Vec<u8> -> Arc<[u8]> for the current API. update: maybe bytes::Bytes as a cheaply cloneable vec analog too?)

it would probably make sense to have the EntryHandle and EntryReader own the underlying types too and then make EntryHandle -> EntryReader an owned conversion. that way you can do fun things like passing EntryHandles over a channel to a pool of workers

---

not sure on the traits specifics