Re: [9fans] Typesetting

[Dan Cross <cross@math.psu.edu>]

Well, we're way off topic for 9fans at this point, and then
again I'm replying to something written a week ago, but, Steve
was nice enough to write back and all....  We should probably
take it off the list, though.

In article <200101172305.XAA19827@whitecrow.demon.co.uk>,
Steve Kilbane <9fans@cse.psu.edu> wrote:
> [snip]
>
>> Ie, get my home directory
>> via FTP each time I want to access it.
>
>That's application-specific. Literally - if you want to get the whole
>directory every time, then maybe. Like you say - how the data is
>used has an effect. File systems sevve applications that want to
>access their contents as filesystems. Data streaming is different.

Thanks, that was my point, worded better.  :-)

>> I think it's largely the same
>> thing with the web; in particular, I want to use the pantheon of useful
>> tools that currently exists on my system for dealing with disk files to
>> deal with data on the web.
>
>As I've already mentioned - it would be nice, but most of those tools
>assume a file system and files containing text.

Yes, but my point is that most of the interesting data that a lot
of people want to work with is text, it's just not in a filesystem.  :-)
Of course there are images, audio and video snippets, and other
such things on the web, but, then those exist on filesystems as well.

>> I mean categorial structure.  Data on the web is, for all practical
>> purposes, completely random.
>
>Ah. Sigh. Again, not only is it effectively impossible to break the
>data down, but adding an ordering is even further. The ordering required
>varies according to how you want to view the data. The data no longer
>belongs to category X, but to category X with a given attribute.

Hmm, see below....

>> Yes, but text, presented in a standard encoding, isolates me rather
>> well.  There's nothing inherent in the browser model which makes it the
>> only tool or the best tool for cross platform data sharing.
>
>Except that it's effectively ubiquitous. Which is a large part of the
>problem.

Yes, you are right there...  But I don't think that means we shouldn't
try to come up with something better!

>> Well, I disagree that it simplifies something which is already simple.
>> Consider creating ``sessions'' over HTTP as an example; I think the
>> methods to do this are ad hoc and complex, if not entirely broken.
>> Using file semantics makes this much easier.
>
>[ open a file to do a session ]
>
>That's not quite the same thing. Opening a connection to a file *server*
>is one thing, while opening a file is something else (and much simpler,
>because the server connection has been done). Again, it depends on the
>protocol. 9P works much better in this circumstance than most, because
>it's designed to operate over a pipe regardless of the medium, and it
>doesn't assume the other end is a Real Disk. I wouldn't call 9P authentication
>simpler than cookies, though - just *much* better defined.

Woah, I never said it was simpler in terms of *implementation*.  I
did say (in an earlier note) that it pushes the complexity down
a layer and away from the application programmer, who shouldn't have
to worry about it.  The application guy shouldn't care that the file
is local or on a remote file server, s/he should just open a ``file''
and read and write to it, just as she shouldn't have to care about
cookies and so on.  (Though she would need a way to get at any
authentication data maintained by the filesystem.)

Sorry, my paragraph quoted above wasn't particular clear on the point.

>> Well, Yahoo! and companies like Yahoo! have (until recently... :-) made
>> a lot of money by organizing web content into a ``hierarchy.'' Sure,
>> not everyone would be happy, but not everyone is happy with the
>> filesystem layout of modern operating systems.
>
>Indeed, but pay attention to who's doing what: users on Yahoo are storing
>data references in certain categories. There's nothing inherent in the
>data itself that causes that, or that supports it. It's an entirely
>subjective viewpoint. Moreover, the categorisation is stored separately
>from the data itself, and it's a web, not a tree. I don't see how putting
>a filesystem on top of that gives you anything different.

It can be said that any organization of data is inherently subjective,
but that doesn't make it any less useful.

The idea of putting a filesystem on top of it is that it allows one to
interact with it in a more natural way, and be less constrained by the
system.

But your points are well taken; I definately agree that not everyone
would be happy with only one way of organizing the data.

>> People seem bent on making the thing interactive, even though it wasn't
>> built with that in mind.
>
>That's true. That's because they're trying to attract your attention, to
>make you buy something. The old marketing approach of using style to
>disguise lack of substance.

Too true!

>> No, I appreciate the comments....  Indeed the problem is difficult.  I
>> think that the general issues are solveable, though.  Oh well, time
>> will tell....
>
>I don't know that the general issues are solvable, given that they contain
>such a high level of subjectivity, but I do think that individual components
>of the whole system can be improved. For example, while a hierarchy can't
>support all the categorisation necessary, Plan 9 can at least offer multiple
>categorisations in the form of multiple hierarchies onto the same data, at
>a cheaper cost than most systems. This isn't necessarily a good thing, though:
>consider the connection server and dns on Plan 9, as opposited to just
>making the whole internet a tree onto the dns.

Yeah, I hear where you're coming from, but I politely disagree.  :-)

I think that we're agreed that the most vexing problem is how to organize
the data.  When you're talking about an organization that makes the whole
world happy, then it just can't be done.  So multiple views onto the data
are necessary.  AFS solves this by tagging each site's content with it's
directory (ie, /afs/psu.edu/...).  Unix users can then create symbolic
links into AFS directory space, effectively customizing the hierarchy to
their needs.  It works reasonably well, except for the dot-dot issue.
Anyway, something similar could perhaps provide an adequate solution.

Thanks again for your comments.

	- Dan C.