Anatomy of a ZIP scheme

With increased exposure of built in compression routines, it's now feasible to write fairly succinct functions that can ZIP/UNZIP (see also Does Ren-C have zip and unzip?).

As always, rather than introduce new functions that would be complex in nature and PHPish in proliferation, I would see a ZIP scheme as the preferred way to interface with ZIP assets.

Implementation Sketches

Here's some thoughts for how this might work:

; Opening

archive: open zip:///Users/Chris/  ; short form maps to filesystem

archive: open [
    scheme: 'zip
    source: %/Users/Chris/

archive: open [
    scheme: 'zip  ; new empty archive
    source: #{}

archive: open [
    scheme: 'zip  ; remote archive
    source: s3://a-bucket/

; Extracting

select archive %path/to/file.reb

select archive [from folder %path/to/]  ; dialect for selecting multiple contained assets

first next archive  ; port offers a series API to access contained assets

; Modifying

append archive [%path/to/new.reb {Rebol []}]

remove archive  ; removes an asset per the series API

; Saving

close archive  ; updates using existing reference

close rename archive %/Users/Chris/

copy archive  ; returns binary copy of archive

Thoughts, critiques, suggestions, etc...


Alternatively as per my XML model, there I use an object to represent an XML document and the same approach could be used for ZIP archives:

; Opening

archive: load-zip %/Users/Chris/ ; or just LOAD with codecs

; Extracting

archive/select %path/to/file.reb

archive/select [from folder %path/to/]  ; dialect for selecting multiple contained assets

; Modifying

archive/insert %path/to/new.reb {Rebol []}

archive/delete %path/to/old.reb

; Saving


archive/write %/Users/Chris/


I don't do any zipping to speak of but this sounds an interesting project.
And I imagine that it would be useful for creating apks ( @giuliolunati ) and epub documents.
However, I'm at the bottom of a deep gravity well at present so can only watch!

Seems like a good idea to me, or even being able to sub-address things...

 data: read zip://wherever/

Still looking for grand-unifying-theory of ports, myself, though.

I suppose I should have mentioned that this is similar to what I envisioned as the encap scheme.

data: read encap://directory/file.dat
png: load encap://graphics/icon.png

etc. So the encap scheme might be layered on top of this zip scheme, somehow.