I've been thinking about my project recently and would like both to make my ideas known and to find out where they have weak points :-)
I suggest creating a libnetfs-based translator which will be set on a directory and will allow the user to access files with special names like 'file1,u'. This name will stand for setting a gunzip translator on 'file1'. If the user tries to access 'file1,u' a second time, nothing will change, because a translator will have already been set on 'file1'. Stacking of translators should be done in an explicit form, like 'file1,u,x' (x might mean xmlfs). When the user tries to access 'file1' , the translated version will be accessed. If the user provides a different list of translators, for example 'file1,u,m' (x is mboxfs, for example), the old list will be discarded and a new stack of translators will be built. Whenever the user wants to get the untranslated version of file1, they will be able to get it using the name 'file1,0'. To remove the top translator in the stack, the user will write 'file1,-'. To remove all translators, the following syntax will be used: 'file1,--' (double dash).
In my vision, the section after the first comma in the filename should become a kind of a shorthand command line for translators. For example, I think it will be quite comfortable if the user could _add_ a translator to the stack, without specifying every single translator. Then, the user could write 'file1,+x' , if they have already accessed file 'file1,u' before. Moreover, if the filename 'file1,u,x' has been already accessed, and a mboxfs translator is wanted above the gunzipped 'file1', it should be possible to write 'file1,-,+m' , asking for removal of the top translator in the stack and adding another.
If the user would like to create a file with commas in the name, they will have to escape the comma, like here: 'Andrew\,Jane\,Mary.jpg'
Somewhere in /etc there should reside a file containing the shorthand names for translators. Of course, not only one-character names will be allowed.
I am afraid I have to remark that I still don't have but a vague image of how a libnetfs translator works, because I've had little time recently. However, I believe I'll fill the gaps in my knowledge soon and will provide more details about the implementation of the enumerated features.