Re: [9fans] Typesetting

Re: [9fans] Typesetting

[Dan Cross]

In article <20010110201239.3ECB619A40@mail.cse.psu.edu> you write:
>I agree that the web has become ugly. How would you
>change it? I think I would reduce it a bit to something
>more content oriented and less driven to "appeal".

I've used a lot of emails to folks as sounding boards for some random
ideas, but unfortunately, it all sounds like kind of incoherent
rambling, as I'm sure this note does.  :-)

In general, I think that the distribution mechanism is all wrong, as is
the fact that there's no decent way to categorize or present the data.
The following facts about goal of the web are relevant:

	+ The web is about information sharing.
	+ The web is content driven.
	+ Most web pages are specific to a given topic area.
	+ The data is often meant to be *used* (by that, I mean
	  not just telling me where the muffler on my car is,
	  but manipulated by me).

So, some things that really don't make sense are:

	+ The distribution protocol is based on file transfer, not sharing.
	+ The markup language doesn't preserve the semantics of the content.
	+ The Markup language doesn't provide a good way to present the data.
	+ There is no built in ordering to the data.
	+ The browser model is all wrong; it doesn't integrate cleanly into
	  the rest of the environment, and effectively prevents me from
	  manipulating the content.

So these are the problems that I think need to be addressed first.  You
can probably see where I'm going with this, but, here goes:

	+ Replace the distribution protocol with a distributed
	  filesystem; something similar to AFS.

		- Instead of having web servers, have file servers.
		- I should never have to talk to more than one file
		  server to get anywhere on the web; kinda like DNS.
		- File servers should cache data using a mechanism
		  similar to that of DNS; that is, each file
		  should have as part of it's metadata a ``time to
		  live'' detailing how long another server may cache
		  the file.  It could use an LRU mechanism to keep
		  the cache size reasonable.  Whole file caching is
		  fine.
		- File servers should provide a network-enabled ``named
		  pipe'' like mechanism to provide interactive services.

	  This simplifies a lot of stuff.  First of all, the
	  scalability problems of current-generation web servers
	  go away.  I don't need a farm of high powered boxes to
	  serve out content; I just need a few file servers.
	  This is kind of like what Akami (sic) et al attempt to do.

	  Second, the ``session handling'' problem goes away for
	  interactive services.  A session is active as long as
	  I have one of these ``named pipe'' like files open.  It
	  goes away when I close the file.

	  It provides a mechanism for built-in proxies, since a
	  client only ever talks to a local file server.  If I
	  need a proxy for some reason, I can just interject a
	  file server between my clients and the rest of the ``web.''
	  I don't have to worry about configuring my firewall to
	  allow everyone's desktop machine to access every web
	  server in the world.  Instead, I just have a single
	  caching file server in my DMZ or outside my firewall
	  that the desktops talk to.

	  The hierarchial organization of the filesystem namespace
	  allows me to easily categorize content.  I can also use
	  this to restrict access to information; if I authenticate
	  to the filesystem, then I can say things like, ``if user
	  is not in acl, don't let him/her see /foo....''  This
	  could be useful for blocking the rest of the world from
	  my internal information, or for blocking the kids from
	  things they shouldn't see.

	+ The next major problem is content markup and presentation.
	  I haven't figured out too much about that yet.  Most
	  content needs something a little more, umm, attractive
	  than plain text to be popular, but it's also important
	  to preserve information about content.  For instance,
	  ``this is a telephone number.''  XML tries to do this,
	  and I think does okay, but it imposes a rigid structure
	  on the data.  That's kind of unfortunate, since it doesn't
	  integrate well with text processing tools like grep et al.

	  Perhaps structured regular expressions and some kind of
	  metalanguage could help out the content structure part,
	  but the markup part is still unsolved.  Perhaps another
	  metalanguage derived from structured regular expressions
	  could help here.  Either that, or treat everything as an
	  object with a ``render'' method, almost what XML does.

Well, that's basically it, sorry it's rather rambling.  There are a
lot of open issues, like authentication and privacy (both of which
are afterthoughts on the web, but must be integral from the beginning
of a new system), etc, but I'd rather solve them at the file server
level than at the application level.

	- Dan C.

Re: [9fans] Typesetting

[William Staniewicz]

I agree that the web has become ugly. How would you
change it? I think I would reduce it a bit to something
more content oriented and less driven to "appeal".

> The danger, I think, comes when we can no longer tell ugly from
> beautiful, as is clearly the case these days.  Too much time is spent
> investing energy in ugly things, like the web and various other
> ``Internet'' things, because people *think* this is what computing
> should look like.  I sure wish I knew how to change that.
> 
> 	- Dan C.

Re: [9fans] Typesetting

[Douglas A. Gwyn]

William Staniewicz wrote:

> I agree that the web has become ugly. How would you
> change it? I think I would reduce it a bit to something
> more content oriented and less driven to "appeal".

It's a matter of upbringing and education.
So long as most people *want* flash rather than depth,
that is what we will have inflicted upon us all.

Re: [9fans] Typesetting

[Boyd Roberts]

From: Douglas A. Gwyn <DAGwyn@null.net>
> 
> It's a matter of upbringing and education.
> So long as most people *want* flash rather than depth,
> that is what we will have inflicted upon us all.

damn straight.

Re: [9fans] Typesetting

[Dan Cross]

In article <3A5CE7B3.7010302@null.net> you write:
>It's a matter of upbringing and education.
>So long as most people *want* flash rather than depth,
>that is what we will have inflicted upon us all.

That's true.  The question is: How to convince the end user to
give up ``flash'' and use something more substantive?  Perhaps
even more important, how to do that with computer scientists?

	- Dan C.

Re: [9fans] Typesetting

[Steve Kilbane]

> In article <20010110201239.3ECB619A40@mail.cse.psu.edu> Dan wrote:
> The following facts about goal of the web are relevant:
> 
> 	+ The web is about information sharing.

Alas, no longer. The web is now about selling something, or
looking "cool". If it was just about sharing information, most
of the current problems wouldn't be nearly so bad. However,
that's a sociological problem, and a technical fix won't help.

> 	+ Most web pages are specific to a given topic area.
> 	+ The data is often meant to be *used* (by that, I mean
> 	  not just telling me where the muffler on my car is,
> 	  but manipulated by me).

In other words, it's got internal structure that's more than just
pixels on the screen, so it should be handled as such.

> So, some things that really don't make sense are:
> 
> 	+ The distribution protocol is based on file transfer, not sharing.

You're linking the use of the data with the retrieval of the data. I don't
think the two are particularly related. The key, I feel, is how you
identify what data is to be fetched next. How you actually get it isn't
really interesting.

> 	+ The markup language doesn't preserve the semantics of the content.
> 	+ The Markup language doesn't provide a good way to present the data.

Both true.

> 	+ There is no built in ordering to the data.

That's arguable, so I think you'd better clarify it.

> 	+ The browser model is all wrong; it doesn't integrate cleanly into
> 	  the rest of the environment, and effectively prevents me from
> 	  manipulating the content.

But that's never going to change, at least until Microsoft (or any other
company) achieve their goal of being the universal platform. While there
is heterogeny, you'll need some way to insulate the data from the destination
platform's weirdness.

> So these are the problems that I think need to be addressed first.  You
> can probably see where I'm going with this, but, here goes:
> 
> 	+ Replace the distribution protocol with a distributed
> 	  filesystem; something similar to AFS. [...]
> 	  This simplifies a lot of stuff.

It does, but unfortunately, it simplifies the stuff that happens to
be simple to begin with. Filesystems are well understood, and so
is data transfer in general. HTTP was a bad start to begin with,
and we've only still got it now because it had a solid foothold.
A side point, though: DNS contains much less information than
a web server. Heavily-accessed sites will still need big systems
because the intermediate nodes on the net can only cache so much,
so many accesses will still make it back to the source machine.

> 	  The hierarchial organization of the filesystem namespace
> 	  allows me to easily categorize content.

I'm sorry to say this, but no chance. Absolutely none. For any
arbitrary information storage system, you can't come up with a
hierarchy that makes sense to more than one segment of the user-base
(unless you count /everything). Different users see things in different
ways, and so need a different hierarchy. Worse, it changes depending
on what they're looking for.

As a simple example, the unbiquitous FAQ: a document ideally written
by an expert, for a non-expert reader. The author and the target
reader have different views of the same information, and would probably
like it presented differently. A tutorial is structured differently from
a reference guide, and that's just the tip of the iceberg.

> 	+ The next major problem is content markup and presentation.
> 	  I haven't figured out too much about that yet.

You and most webmasters. :-)

> Most
> 	  content needs something a little more, umm, attractive
> 	  than plain text to be popular,

Which takes me back to the original point about what the focus of
the web is, nowadays. As it happens, I agree with the masses here,
albeit for different reasons. The commercial sites want pages that
look snazzy, whereas I want pages that get the information into my
brain in the fastest possible way, in a manner I understand. If this
means images, animations, etc, then fine - but only if that's the
best way. It also probably needs an expert in visual aids to pull it
off, and that's a rare talent.

> but it's also important
> 	  to preserve information about content.  For instance,
> 	  ``this is a telephone number.''  XML tries to do this,
> 	  and I think does okay, but it imposes a rigid structure
> 	  on the data.  That's kind of unfortunate, since it doesn't
> 	  integrate well with text processing tools like grep et al.

But then, how do you grep a 3d model? If you want your information
to be more than unstructured text, you need different data manipulation
tools.

I realise I've been purely negative here, but I don't have any constructive
comments to make. I worked on the sort of thing you're after (a "knowledge
management system" - ick), and I didn't gain much in the way of answers.
Mainly, I got an appreciation of how hard the generic problem is.

steve

Re: [9fans] Typesetting

[Randolph Fritz]

On Thu, 11 Jan 2001 09:50:51 GMT, Douglas A. Gwyn <DAGwyn@null.net> wrote:
>It's a matter of upbringing and education.
>So long as most people *want* flash rather than depth,
>that is what we will have inflicted upon us all.

I'm not quite sure what's meant here...most web users do not want
advertising.

Randolph

Re: [9fans] Typesetting

[Dan Cross]

In article <200101120031.AAA22053@whitecrow.demon.co.uk>,
Steve Kilbane <steve@whitecrow.demon.co.uk> wrote:
>
>  [snipped some insightful stuff]
>
>> 	+ The distribution protocol is based on file transfer, not sharing.
>
>You're linking the use of the data with the retrieval of the data. I don't
>think the two are particularly related. The key, I feel, is how you
>identify what data is to be fetched next. How you actually get it isn't
>really interesting.

...But how the data is used might give insight into the most efficient
way to transmit it.  For instance, it wouldn't be efficient, in terms
of computational resources or in terms of people's time, to use file
transfer protocols in distributed computing.  Ie, get my home directory
via FTP each time I want to access it.  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.

The ways I find to do this are clumsy at best; largely because of
complications due to the distribution mechanism.

>> 	+ There is no built in ordering to the data.
>
>That's arguable, so I think you'd better clarify it.

I mean categorial structure.  Data on the web is, for all practical
purposes, completely random.

>> 	+ The browser model is all wrong; it doesn't integrate cleanly into
>> 	  the rest of the environment, and effectively prevents me from
>> 	  manipulating the content.
>
>But that's never going to change, at least until Microsoft (or any other
>company) achieve their goal of being the universal platform. While there
>is heterogeny, you'll need some way to insulate the data from the destination
>platform's weirdness.

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.

>> So these are the problems that I think need to be addressed first.  You
>> can probably see where I'm going with this, but, here goes:
>> 
>> 	+ Replace the distribution protocol with a distributed
>> 	  filesystem; something similar to AFS. [...]
>> 	  This simplifies a lot of stuff.
>
>It does, but unfortunately, it simplifies the stuff that happens to
>be simple to begin with. Filesystems are well understood, and so
>is data transfer in general. HTTP was a bad start to begin with,
>and we've only still got it now because it had a solid foothold.
>A side point, though: DNS contains much less information than
>a web server. Heavily-accessed sites will still need big systems
>because the intermediate nodes on the net can only cache so much,
>so many accesses will still make it back to the source machine.

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.

Regarding intermediate nodes caching so much, yes, this is true, but if
intermediate nodes use an LRU mechanism to maintain the cache, I'm
willing to bet that very heavily used sites will stay in a lot of
caches for a lot of the time (I have no empirical evidence to back that
up, obviously).  What's more, there are fewer intermediate nodes
contacting the origin site, which would have an effect on the system's
overall scalability.

>> 	  The hierarchial organization of the filesystem namespace
>> 	  allows me to easily categorize content.
>
>I'm sorry to say this, but no chance. Absolutely none. For any
>arbitrary information storage system, you can't come up with a
>hierarchy that makes sense to more than one segment of the user-base
>(unless you count /everything). Different users see things in different
>ways, and so need a different hierarchy. Worse, it changes depending
>on what they're looking for.
>
>As a simple example, the unbiquitous FAQ: a document ideally written
>by an expert, for a non-expert reader. The author and the target
>reader have different views of the same information, and would probably
>like it presented differently. A tutorial is structured differently from
>a reference guide, and that's just the tip of the iceberg.

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.

>> 	+ The next major problem is content markup and presentation.
>> 	  I haven't figured out too much about that yet.
>
>You and most webmasters. :-)

:-)

>> Most
>> 	  content needs something a little more, umm, attractive
>> 	  than plain text to be popular,
>
>Which takes me back to the original point about what the focus of
>the web is, nowadays. As it happens, I agree with the masses here,
>albeit for different reasons. The commercial sites want pages that
>look snazzy, whereas I want pages that get the information into my
>brain in the fastest possible way, in a manner I understand. If this
>means images, animations, etc, then fine - but only if that's the
>best way. It also probably needs an expert in visual aids to pull it
>off, and that's a rare talent.

Yes, interesting.

My point is more, do I want the web to be an online brochure (or maybe
data sheet, whatever), or do I want it to be something that I can
interact with?

People seem bent on making the thing interactive, even though it wasn't
built with that in mind.

None of this precludes the hiring of graphic artists and presentation
specialist who make sure the information is presented in a digestible
manner.  I'm sure they could do a better job than ``Dan becomes an
artist for a day!''  :-)

>> but it's also important
>> 	  to preserve information about content.  For instance,
>> 	  ``this is a telephone number.''  XML tries to do this,
>> 	  and I think does okay, but it imposes a rigid structure
>> 	  on the data.  That's kind of unfortunate, since it doesn't
>> 	  integrate well with text processing tools like grep et al.
>
>But then, how do you grep a 3d model? If you want your information
>to be more than unstructured text, you need different data manipulation
>tools.

Indeed.  I had a lengthly discussion with a friend of mine the other
night where we discussed this very topic.  We didn't come up with any
answers.

>I realise I've been purely negative here, but I don't have any constructive
>comments to make. I worked on the sort of thing you're after (a "knowledge
>management system" - ick), and I didn't gain much in the way of answers.
>Mainly, I got an appreciation of how hard the generic problem is.

No, I appreciate the comments....  Indeed the problem is difficult.  I
think that the general issues are solveable, though.  Oh well, time
will tell....

Here's my joke for the day: The web is the PC architecture of the
Internet: masses of incompatible and abstruse standards fighting each
other.  :-)

	- Dan C.

Re: [9fans] Typesetting

[chad]

> 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.

I agree that the current methods for HTTP sessions are poor, but I
don't see how file/filesystem semantics improves the situation.  Care
to explain?

> Regarding intermediate nodes caching so much, yes, this is true, but if
> intermediate nodes use an LRU mechanism to maintain the cache, I'm
> willing to bet that very heavily used sites will stay in a lot of
> caches for a lot of the time (I have no empirical evidence to back that
> up, obviously).  What's more, there are fewer intermediate nodes
> contacting the origin site, which would have an effect on the system's
> overall scalability.

 From a previous life, I can tell you that most caches have very high
hit rates, typically better than 90%.  I don't have any data from the
past year or so, though, and heavily `interactive' content is
typically not cached.

> People seem bent on making the thing interactive, even though it wasn't
> built with that in mind.

I claim that people want to make the thing interactive because,
technical qualities aside, the web managed to be the first easily
cross-platform communications means in the burgeoning Internet.  On
the other hand, it seems to be a common pattern for certain classes of
systems; take a look at the specification for Gopher+ sometime. (for
amusement's sake :-)

chad

Re: [9fans] Typesetting

[Micah Stetson]

> the other hand, it seems to be a common pattern for certain classes of
> systems; take a look at the specification for Gopher+ sometime. (for
> amusement's sake :-)

I know this isn't what you were talking about, but if anyone
is interested, I threw together a very primitive gopher client
for Acme a week or so ago.  It isn't Gopher+ (Gopher- is more
like it), but it can pull Tarzan of the Apes off the Wiretap
archive...  I'll post it if anybody has a use for it.

Micah

Re: [9fans] Typesetting

[Dan Cross]

In article <200101170255.f0H2twg01506@egon> you write:
>> 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.
>
>I agree that the current methods for HTTP sessions are poor, but I
>don't see how file/filesystem semantics improves the situation.  Care
>to explain?

Sure.  My original post outlined an idea for using files as endpoints
for IPC in a larger distributed system.  Ie, open a file, you're actually
talking to a process on another system.  Plan 9, of course, already does
this, and Unix has a more limited versions (named pipes, Unix domain
sockets though they're more complex to work with).

Given that, sessions become simple: Open a file, start a session.  Close
the file, end the session.

Implementation wise, it's probably more difficult than, eg, cookies, but
it pushes the complexity down a layer (into the filesystem) where the
application programmer doesn't see it.

As an aside, assuming you can have byte-oriented file operations, the
level of interactivity at that point can go up in the same way it would
going from a 3270 to a VT100 in the terminal world.

	- Dan C.

Re: [9fans] Typesetting

[Steve Kilbane]

> ...But how the data is used might give insight into the most efficient
> way to transmit it.  For instance, it wouldn't be efficient, in terms
> of computational resources or in terms of people's time, to use file
> transfer protocols in distributed computing.

That depends on the file transfer protocol. Microsoft's aren't great
in this area. :-)

> 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.

> 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.


> 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.


> >But that's never going to change, at least until Microsoft (or any other
> >company) achieve their goal of being the universal platform. While there
> >is heterogeny, you'll need some way to insulate the data from the destination
> >platform's weirdness.
> 
> 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.


> 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.

> 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.

> My point is more, do I want the web to be an online brochure (or maybe
> data sheet, whatever), or do I want it to be something that I can
> interact with?
> 
> 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.


> 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.

steve

Re: [9fans] Typesetting

[Dan Cross]

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.

Re: [9fans] Typesetting

[Andy Newman]

Laura Creighton wrote:
>1. One question is whether or not Knuth has access to a C/A/T
>phototypesetter.

In the lecture I mentioned previously he refers to raster typesetting
equipment. Don't know whose (and the book is in the shelf).

>The consensus among pre-computer font designers is that there is, by definition
>no such thing as a beautiful font that can be described by a high level
>description which transcends itself.

I think what Knuth was referring to was mathematical descriptions of
typefaces that allow manipulation and auto-generation of font variants.
I don't know if even Donald Knuth would attempt some meta-physical
leap for typesetting.


>Some of the beauty is in that it *is*.  And Kepler's beautiful music-of-the-
>spheres model had to be scrapped because it was wrong.

And as our approximations get closer (better physics) does the
beauty disappear?  No (but our appreciation of the beauty
may change).  Having a more correct mathematical description of
something doesn't alter the inherent properties of that thing
(ignoring quantum-level stuff).  The type designers who denigrated
computer-based systems were probably inflicted with the earlier systems
that did an even worse job than the ones we use today.  However there
have surely been some very lovely typefaces (and documents) generated
using computerized systems.



>After all, the reason that the fonts produced were ugly could be that
>the designers were lousy, and there is every reason to expect them to
>be lousy at it because most people who started designing fonts with
>METAFONT were computer people ... i.e. people with little or no formal
>artistic training, who were doing this for the first time, often in the
>mistaken belief that what they were doing ought to be easy.

This is probably almost certainly true.  For a large part of the last
15 years I've worked with graphic artists (building them new tools).
The experience gained was...

    Leave the graphics and presentation to them, just give them
    the tools they need to perform their work (i.e, new things that
    get around the problems with the old tools).  Oh, and listen to
    what they say about presentation or just get them to do the work.
    It'll look a lot better in the end. If not, either become a graphic
    artist - you're pretty good at it - or get rid of the bad artists
    you hired and find some good ones.


The big trick is finding these tools.  We've only barely scratched
the surface and we're suffering from limited abilities - ref.  the
many complaints raised here.  Our layout algorithms don't have the
abilities of human typesetters and we're not really sure what is the
best way to let people represent documents - we're sure settling on a
well-defined set of techniques...

    output = render(layout(style(content)))

Now a bunch of people of re-writing everything to fit with the new
data mantra - XML.  In presentation terms they're mostly still
back in the 1960s but progress is being made - some people are
converting all the X.. stuff to TeX for final output rather than
writing their own layout engines and can actually print things.

And the output devices are only now getting really good and cheap enough
to use everywhere (screens are still hampered by low resolutions but print
is getting good - close to 1000dpi is becoming commonplace).


>I am curious as to what font design is like in Japan or other places where
>there is a strong tradition of calligraphy and where letters, like bricks
>or phonemes do not exist.  What do Japanese font designers say it takes
>to make a good font?

Having seen large amounts of Japanese output and been exposed to some
Japanese typesetting (people I used to work for/with do a lot of it)
I'd have to caution that many Japanese presentations have a certain
aesthetic that may not immediately appeal to those accustomed to
traditional western presentations.

That's too polite...  Man, do they have some crazy designs!  All flashing
lights and colors and wild lines and cliparts.  A lot of it really looks
ugly to my western conditioned eyes.   So you might not get the answer you
were expecting :)



>Laura Creighton


-- 
Andy Newman

Re: [9fans] Typesetting

[okamoto]

[-- Attachment #1: Type: text/plain, Size: 885 bytes --]

>I bet they say it takes a lifetime of study, apprenticeship, practice, and
>learning, pretty much as it does here.

You must have had some negative experience with someone Japanese.
I suspect something wrong relation between this mailing-list and Japanese
proffesionals of computer science,  because I have no reply on my querry 
on Toshiba's floppy drive, which is very familiar machine here.
I got, however,  a Japanese book describing "Japanese standard" of floppy 
drive, and may be able to find something.

Anyway, I found more than 40 peoples got my update of Japanese106 
keyboard for plan 9 in these several days, which is not neccessary for
others who is not running Plan 9.  Therefore, I think there are some more
people who is running Plan 9 here, even if they may not be any proffesional
on computer science, thay may help our future, I believe.

Kenji


[-- Attachment #2: Type: message/rfc822, Size: 1652 bytes --]

From: "rob pike" <rob@plan9.bell-labs.com>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] Typesetting
Date: Wed, 10 Jan 2001 12:47:45 -0500
Message-ID: <20010110174802.A9CE319A5F@mail.cse.psu.edu>

	What do Japanese font designers say it takes to make a good font?

I bet they say it takes a lifetime of study, apprenticeship, practice, and
learning, pretty much as it does here.

-rob

Re: [9fans] Typesetting

[Dan Cross]

In article <200101101724.SAA08377@boris.cd.chalmers.se> you write:
>2.  This is a quote from the Metafont book.  chapter 1 page 1  (paragraph 2)
>
>	Why is the system called METAFONT?  The FONT part is easy to
>	understand, because sets of related characters that are used
>	in typesetting are traditionally known as fonts of type.  The
>	META part is more interesting:  It indicates that we are interested
>	in making high level descriptions that transcend any of the
>	individual fonts being described.
>
>(Okay. So ``transcendence'' is not some woolly idea that I am bringing up
>because I lack mathematical rigor or even common sense.  It is the design
>goal of the whole project.)
>
>The consensus among pre-computer font designers is that there is, by definition
>no such thing as a beautiful font that can be described by a high level
>description which transcends itself.  Fonts are *wholly* immanent, and are
>indeed a refutation of the Platonic theory that you can find some ideal
>font that all fonts are the reflection of.  Each font can only be utterly
>what it is in relevance only to itself  and the materials one uses to print
>it ... ink and paper.  The entire beauty of a font comes in the things
>which make it uniquely what it is and what nothing else can be.  A font is
>like a tree, or a collection of pebbles.  Only the trivial and boring
>bits about it can be abstracted out ... the part where a a font becomes
>beautiful or not is precisely where is cannot transcend.

I'm not entirely sure I agree.  I understand what you're saying, but a
letter ``A'' is a letter ``A'' wether rendered in one font or the
other.  Adding metadata to font descriptions allows me to relate facts
about symbols rendered in one font to symbols rendered in another (ie,
this symbol represents the letter ``A'').  I'm not sure it's any deeper
than that.  Then again, I haven't read Knuth's books on the subject.

On another note, Forsyth's comment relating eg Kepler's work to
software is insightful.  We must juxtapose beauty with necessity,
however; Real-world business and time constaints sometimes force us to
do things we'd rather not.  Sometimes I don't have time to come up with
something elegant (though I've long said that the only way to get
maintainable software is to make it elegant), yet the software must be
given to the customer who has to put it into production yesterday.
C'est la vie.

The danger, I think, comes when we can no longer tell ugly from
beautiful, as is clearly the case these days.  Too much time is spent
investing energy in ugly things, like the web and various other
``Internet'' things, because people *think* this is what computing
should look like.  I sure wish I knew how to change that.

	- Dan C.

Re: [9fans] Typesetting

[forsyth]

>>And Kepler's beautiful music-of-the-spheres model had to be scrapped because it was wrong.

it's an interesting contrast with software: today, something might be not only wrong but ugly,
yet we end up being stuck with it for ever, it seems.

Re: [9fans] Typesetting

[rob pike]

	What do Japanese font designers say it takes to make a good font?

I bet they say it takes a lifetime of study, apprenticeship, practice, and
learning, pretty much as it does here.

-rob

Re: [9fans] Typesetting

[Boyd Roberts]

> I am curious as to what font design is like in Japan or other places where
> there is a strong tradition of calligraphy and where letters, like bricks
> or phonemes do not exist.  What do Japanese font designers say it takes
> to make a good font?

japanese does have 'letters'.  they're called the 'kana'
[hiragana + katakana].  they are phonetic.  you can write
anything with hiragana [japanese] and katakana [foreign
words].  hiragana is used with the kanji [ideographs]
to write 'pure' japanese.

eg: mimasu - verb to see

    written:

        mi [kanji] ma [hirigana] su [hirigana]

    three characters

[9fans] Typesetting

[Laura Creighton]

1. One question is whether or not Knuth has access to a C/A/T
phototypesetter.  They were not that common.  I can't remember when
the company folded either, was it bought by WANG or something? I could
go look at 20 year old mail and see, I suppose, except I think that
mail is backed up on 9-track.

2.  This is a quote from the Metafont book.  chapter 1 page 1  (paragraph 2)

	Why is the system called METAFONT?  The FONT part is easy to
	understand, because sets of related characters that are used
	in typesetting are traditionally known as fonts of type.  The
	META part is more interesting:  It indicates that we are interested
	in making high level descriptions that transcend any of the
	individual fonts being described.

(Okay. So ``transcendence'' is not some woolly idea that I am bringing up
because I lack mathematical rigor or even common sense.  It is the design
goal of the whole project.)

The consensus among pre-computer font designers is that there is, by definition
no such thing as a beautiful font that can be described by a high level
description which transcends itself.  Fonts are *wholly* immanent, and are
indeed a refutation of the Platonic theory that you can find some ideal
font that all fonts are the reflection of.  Each font can only be utterly
what it is in relevance only to itself  and the materials one uses to print
it ... ink and paper.  The entire beauty of a font comes in the things
which make it uniquely what it is and what nothing else can be.  A font is
like a tree, or a collection of pebbles.  Only the trivial and boring
bits about it can be abstracted out ... the part where a a font becomes
beautiful or not is precisely where is cannot transcend.

Thus, non-computer font people, hearing of TEX were firmly convinced that
nothing beautiful could ever be produced with it because METAFONT was a
true heresy, an attempt to substitute mathematical beauty for the beauty
of real physical things.  It was a very cool and fascinating heresy because
there is something deep in the heart of all people who love mathematics to
wish that font design was a place where mathematical beauty was responsible
for font and font family beauty.  I feel almost the same way reading about
Kepler's early attempt to model the positions of the planets based on
constructable regular sided solids.  It would be *so* *cool* if it had been
that way.  But the beauty of the solar system is only partially mathematics.
Some of the beauty is in that it *is*.  And Kepler's beautiful music-of-the-
spheres model had to be scrapped because it was wrong.

However, it is impossible to prove that the old-time font designers were
correct and that Knuth was persuing a delusion.  After all, the reason that
the fonts produced were ugly could be that the designers were lousy, and 
there is every reason to expect them to be lousy at it because most people
who started designing fonts with METAFONT were computer people ... i.e.
people with little or no formal artistic training, who were doing this for
the first time, often in the mistaken belief that what they were doing
ought to be easy.

I am curious as to what font design is like in Japan or other places where
there is a strong tradition of calligraphy and where letters, like bricks
or phonemes do not exist.  What do Japanese font designers say it takes
to make a good font?

Laura Creighton