Add API for supporting other archive types

[lee-dohm]

This should follow the Behavior Services pattern to allow community packages to add support for other archive types to archive-view.

[Alhadis]

This sounds like fun, to be honest.

I'll have a crack once things have settled over at File-Icons.

@lee-dohm Should this necessarily be restricted to showing file-lists? For gzipped files (as described in #30), this should logically open the uncompressed file data instead.

[lee-dohm]

Hmmmm ... that's interesting 🤔

If we can:

1. Make it clear that the data isn't editable or
2. Make the view/edit roundtrippable

I think it would be cool either way 👍

[Alhadis]

How about this?

A decompressors service returns a Promise that resolves either to an array or to a DOM element. An array is expected to contain objects which archive-view uses to construct the final pane-item:

[
	{ name: "root-1",          type: "directory"},
	{ name: "root-1/file.txt", type: "file"},
	{ name: "root-2",          type: "directory"},
	{ name: "root-2/subdir",   type: "directory"},
];

A DOM element is considered a "precomposed" pane-item, added to the current pane. This gives providers an opportunity to decompress and display any data, and solves #30. Having an optional secondary argument will also solve the problem of opening individual files inside the archive:

consumeDecompressors("/path/to/file.zip", "root-1/file.txt");

[lee-dohm]

Maybe an additional "can you handle this file" method on the service object also? So that multiple packages can offer decompressors? Or would a decompressor's promise just resolve to undefined if it doesn't handle that file type?

[Alhadis]

I'd prefer the former, as it's much clearer what a package can and can't open.

[lee-dohm]

Makes sense to me 👍

[Alhadis]

To make things easier, I'll wait for atom-space-pen-views to be axed before starting, though.

[winstliu]

To make things easier, I'll wait for atom-space-pen-views to be axed before starting, though.

JavaScript and Etch have arrived :)

[stadelmanma]

I ran into this limitation today, and maybe a good baby step to make is to allow users to add file-type aliases that match up with already supported compression schemes. The main example that affects me would be mapping ".docx" to ".zip".

I don't know exactly how this would be implemented on your end but I can't imagine I high degree of difficulty since all the important pieces are already available and the "actual name" of a file should be irrelevant once you get below the pretty user interface that "expects" filename to behave a certain way. Seems loosely related to atom/node-ls-archive#5

For more detail on my use case, I'm programmatically modifying/generating docx files and while debugging various issues I have to constantly rename the extension which gets cumbersome after awhile. I tried various hacks to get this working via the Atom init script to no avail.

Directly related to but more general than #49, since it moves the "config" work to the end user instead of adding more maintenance on your side.