SkyOS Forum

Will the filesystem browser accept plug-ins to deal with "pseudo-folder" like files (all archive types like .tar/.tgz, .gzip, .bzip2, .z, .zip/.jar/.ear/.war/.ratDVD/..., .7z, .rar, .arj, .arc, .cab, .lzh, .pak, .ha, .zoo, .ace, .j, ..., .cpio, .deb, .rpm, ..., .iso, .ccd, .bwt, .cdi, .pdi, .b5t, .img, .nrg, .mds, .bin, ...) ?

Will the user be able to browse through these archive files like it would in a (at least) read-only "virtual folder" ?

Well, these "filesystem browsing plug-ins" should be at a lower level than the Filesystem Browser App (erm... at the filesystem API level (!?) ) so that the IndexFeeder would index at a deeper level on these files.


hmmm... am I making any sense here ?

PS: As always, I tried to search the forum for this, but found nothing. If this is duplicate, please forgive me.

EDIT: Found something related to this at
http://www.skyos.org/board/viewtopic.ph ... r&start=75

I'm really curious to see how the "builtin" archiver will be implemented. Will it be just another App or will it do some of what I was asking on this thread, although not through filesystem plug-ins (but at least supporting some sort of plug-in so one can care for new future formats of archive type files)

I think pseudo-folders or virtual folders a la spotlight should not be difficult to implement. You could see this as a simple shortcut to a search query.

It would be really nice if this was possible.

If one could "plug" these things into the filesystem, it would be "easy" to keep up with new "archive" type file formats.

This way the user can browse through these archives like it browses any other folder and, as an added bonus, the IndexFeeder could also index files (usually "hidden" inside these archives) seamlessly without any need for special IndexFeeder plugins to understand some archive files.

If the archive file format supports easy implementation of on-the-fly write-in, the better (like ZipFolders did on Windows, and I think XP does also with .zip files only... XP calls it Compressed Folders). If not, at least it would present the user with a read-only "folder".

To me, *all* OSs should deal equally with directories and archive type files because all these are (compressed or not) *folders*, from a user point of view.

So, instead of using a SkyZip app, a SkyRAR app, SkyUNTAR app, etc... or mount/unmount a .iso file, all these files could be dealt by the filesystem plugin (or at least by the filesystem browser app plug-in).

I see the use of a specific app for some archive formats only when, for a performance or implementation reason, the plug-in philosophy couldn't deal with the update of that archive file.

I'm sure that this will be given consideration before 5.0 final.

That would be great ! ...at least to give it a thought, because as SkyOS continues to grow with features, it's becoming closest to *the* desktop OS I wished I could have

Oh and don't forget to give the user the option to turn off (or configure when needed) those plug-ins, of course, because some could have a big impact on system resources.


I can't see in the videos, but is this already possible (turn off/configure) with the IndexFeeder plug-ins ?


Kudos to Robert and all SkyOS team.

IndexFeeder is a plug-in, just like the Integrated Streaming System or File Sharing, so of course it can be switched off.

I understand that IndexFeeder may be called a SkyOS "plug-in" (service?).
On the other hand, IndexFeeder has its own plug-ins to feed it with info about the files being scanned/touched. Right?

I can't really see, from the Videos, if configurable IndexFeeder plug-ins are something Robert thought about.

So, I was asking if the IndexFeeder service dialog is prepared for configurable plug-ins and for choosing which ones to turn off.

Examples: Imagine an IndexFeeder plug-in that knows how to deal with:

1) .PDF's. Imagine I don't want to index the content of .PDF's but want to have SkyOS attributes added about Author, Title, etc of those .PDF's. I would simply configure that IndexFeeder plug-in to do just that and not add content to the Index Content Database.

2) .OGM's. I can configure it to index the Subtitle streams to the Index Content Database.

3) AudioCD's. I may not want to index anything about those. So I simply turn that plug-in off. On the other hand, it would give an option to configure the correct URL for a CDDB compatible service.

...

Speaking about this thread subject, "Filesystem plug-ins", I was sugesting if something like it becomes a reality, to not forget to care for configurable plug-ins also. That and the possibility to turn some off or on.

Because, if someone makes a filesystem plug-in to represent .URL files as folders (maybe only directory browsable HTTPs or FTPs, connecting to that URL each time one "enters" that "folder"), one may want to turn that one off because sometimes that can become a noisance.

Also, one could have a filesystem plug-in to represent .lnk-like files pointing to folders being represented also as folders, so they show as folders on a tree view. That could turn out to be a little confusing for some users or systems, and one might want to turn that off too.

Anyway, one must remember also that the disk space usage/free calculation algorithm shouldn't consider virtual folders, or at least make a distinction between true and virtual filesystem sizes.

hmmm... I've never seen "virtual folders a la spotlight" in action, but if it works as I'm thinking it does (like a live virtual folder, showing an updated version of the embedded query in real-time ?) then that could be implemented with a "filesystem [browser] plug-in" that would show any saved-IndexFeeder-query files as Virtual Folders

I think I saw on the videos the possibility of saving IndexFeeder queries.