|>Phillip writes:
|>
|>> It is important to distinguish two cases :-
|>>
|>> 1) Loading all data segments associated with an object (eg html + inline
|> images)
|>>
|>> 2) Contiuous mode connection for realtime response.
|>>
|>>
|>> 1 is solved best through use of MIME multipart type. The browser does a
|> request
|>> and gets back the complete object as a single document, inline images and all.
|>> This is currently being added to the library but slowly :-(
|>
|>This is a terrible way to solve that problem. Being able to serve and
|>handle MIME multipart type objects is a good thing, but it should not be
|>used to pre-package all inline images.
I think that this misses the point. We are used to having this idea of images
being separate from the text only because that is the way our tools are
oriented. What I was suggesting is that in many cases there are texts that
have a direct relationship to an image and to have one without the other is
pointless. For example an art gallery where each image has a descriptive text.
We have to handle multipart soon because the mail viewer should do mime.
BTW could a few people send some multipart mime with images etc to me on
dxal18? I need some test data.
The reason why inline images can be cached so well at the moment is that in the
most part they are abused. They add no semantic content, just look pretty
and are liberaly spread about the place just in case you missed them the
first time.
The idea of prepackaging a multiformat document as a mime is not appropriate
if the inline images are merely icons that are regularly reused. In other
cases prepackaging is appropriate. Only the author can really tell.
|>> There are two ways of doing this :
|>>
|>> 1) The server sends back everything as a unit
|>> 2) The client requests the inline images separately.
|>>
|>> The Server is actually in the best position to know whether an image
|>> is specific to one html or shared by many.
|>
|>I disagree. No one knows this, not even the original author. The presence
|>of hierarchical caches makes any such supposition impossible.
Of course the original author can know this in many cases but not every case.
So if the author does not know they do not encapsulate.
|>> I want to have
|>>
|>> GET /path/ http/1.0
|>> Relative-URI: fred.html
|>> Relative-URL: jim.html
|>
|>I don't like the idea of using headers to indicate something that is
|>clearly a different method. I particularly don't like those two because
|>they fail to indicate their purpose. I would much prefer an "MGET" method
|>which can operate on a list of URIs or include that list as request content,
|>e.g.
|>
|> MGET <uri>.mget HTTP/1.1
This would mean very long method lines which would break many servers. Plus
there is no real difference between a single get and a multiple get. The
operation is on a different object, that is all. It is on a composite object
that is the sum of all the parts.
|>As for security issues, I am increasingly convinced that they belong in
|>an entirely separate protocol -- one that may be initiated by an HTTP
|>request, but only confirmed and maintained via a non-HTTP session.
HTTP without security is not much use. Security objects are no different
from any other, they can be refered to by URL or URN. They can be retreived.
|>>...
|>> A second method of doing MGET is to permit wildcarding in a URL. For example
|>> it would be nice to be able to specify a hierarchy of directories as is
|>> possible under VMS.
|>>
|>> [hallam...]
|>> /hallam///
|>>
|>> To me it looks like the only way of doing this extension in a compatible
|>> manner is to use a tripple slash. Weenie UNIX servers then would return the
|>> root directory only. Extended servers would send back the tree. We saw this in
|>> htyper-G yesterday and it was very nice. Yes I know that the UNIX rules for
|>> filename relativity may break but there is no reason why WWW URLs should
|>> be slaves to UNIX. Since few people are using tripple slashes at the moment I
|>> suggest that we have an opportunity for extension without backwards
|>> compatibility problems.
|>
|>ABSOLUTELY NOT!
|>
|>The "/" character in URL paths has a very significant meaning -- using it
|>like this would break every attempt we have made at standardizing the URL
|>syntax. If you want to make special exceptions for WWW, just use the '*'
|>character on its own. That character is not allowed unencoded in a URL,
|>and thus would not likely conflict with normal use anyway.
I was proposing that it be valid for all protocols, not just http. We could
however use
/hallam Non Recursive directory
/hallam/* All the objects in the directory
/hallam/** directory tree
/hallam/*** All the objects in the directory tree
So GET /hallam/* would return a multipart with all the objects in the
directory in it.
This sort of thing would not be too usefull for clients but very nice for
other applications.
-- Phillip M. Hallam-BakerNot Speaking for anyone else.