[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-bugs-dist
Subject:    [Bug 102265] nested kioslaves for archives
From:       Andy Koppe <andy.koppe () gmail ! com>
Date:       2005-04-01 9:57:25
Message-ID: 20050401095725.16725.qmail () ktown ! kde ! org
[Download RAW message or body]

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
         
http://bugs.kde.org/show_bug.cgi?id=102265         




------- Additional Comments From andy.koppe gmail com  2005-04-01 11:57 -------
Looking at these examples, the bracketing scheme appears rather awkward to parse for \
a human, because it's difficult to match the curly braces without explicitly counting \
them. Of course in the usual cases with only one or two nesting levels this wouldn't \
be a problem, but still ...

The multi scheme deals better with deep nesting, but it has other problems.

First, 'multi:' itself is an implementation detail that shouldn't be visible to the \
user, who is only interested in where the data is, not how to glue components for \
accessing it together.

Second, it raises the question of how to deal with nested multis.

Third, the syntax does not reflect the fact that data filters like 'tar' or 'gzip' \
are conceptually different from data sources like 'http' or 'file'. Therefore, it \
permits things like these:

  multi:file:///home/me/file.zip,http://host
  multi:gzip:,zip:/file

Because of the problems with both the bracketing and the multi schemes, I would like \
to throw the pipe syntax I had mentioned earlier back into the mix:

  file:///home/me/file.zip|zip/file.tar.gz|gzip|tar/file.tar.bz2|bzip2|tar/file.txt

This copes well with deep nesting and clearly distinguishes between data sources and \
filters.


[prev in list] [next in list] [prev in thread] [next in thread]