> My name is Marco Scheurer, I am one of the author of SpiderWoman, a
> (marginally functional) WWW client for NEXTSTEP currently under development.
yes, we saw the announcement in november, but have been waiting for a version
that runs under 3.3 (without EOF).
> I find the idea of passing base url to viewers, and to extend the
> in/out messaging capability of WWW clients very interesting.
i suspect that you saw my posting to the omnigroup list (i've been posting
the same thing to them for a year, typically to dumbfounded silence,
though they seem a bit livelier there of late). you can find more information
at http://xxx.lanl.gov/hypertex/ which discusses the hypertex initiative
(and mark doyle [doyle@mmm.lanl.gov] is working on a much enhanced version
of hypertexview.app that implements multiwindows and our half of the url
messaging for live documents, will be ready to post within a week or two).
in case not, what i said yesterday to omni* was:
moreover it will be necessary that they allow passing arguments such as
base url to network aware external apps (e.g. pdf acrobat, hyperps,
or hyperdvi viewers -- not everything one opens is a network vanilla image
or sound file) so that internal relative url's can be handled.
this can be done either as explicit arguments (generalizing mailcap's %s )
or preferably as environment variables (which will generalize to passing
other html metainformation from mime headers -- see
http://www.w3.org/hypertext/WWW/Protocols/HTTP/Object_Headers.html#link ).
tanmoy (tanmoy@qcd.lanl.gov) tells me:
this was discussed on some www list at some point back, and it was proposed
that any HTML metainformation element (allowed withing the HEAD as opposed to
BODY element of the document) be a valid candidate for an HTTP object header.
LINK is one example, TITLE another.
One suggestion was that the isomorphism should be realized by
prepending "WWW-" to the HTML element name to make the HTTP header
name, and the HTML attributes imply identically named
semicolon-separated MIME-style header parameters. It is open to
discussion whether the "WWW-" should be inserted or not.
thus it seems that some day for example
WWW-Base: href="http:..."
could be a valid header.
> For instance, WebStep has standardized on a pasteboard type to
> carry URI between applications. An extension of that would be to
> allow, as you propose, a (base, relative) url pair on this or
> another pasteboard.
that would be essential (as also mentioned in the hypertex/ document) since
we'd like to be able to message such a pair back to our www client
and let it do the reassembly and handle all the http transport functions
(that's the way modular object oriented functionality should work).
i lobbied for many months to get this out of ncsa for mosaic, finally
got an agreement from them late last summer. now of course they're
irrelevant (and besides haven't done anything). getting any sensible response
out of the same myopic netscape people is equally frustrating.
> Do you have a proposal for an environment variable (or mailcap
> extension) to pass the base url to a viewer?
well one example would be WWW-Base as above for environment variable.
i spoke to tim b-l and dave raggett about this in france last summer,
and tim said he would try to implement a standard for this (though he was
busy with the move to mit to head the w3 consortium). when i saw
him in cambridge last month, he said his main priority was still a standard
for the secure shttp. perhaps you could contact him and find out what the
likely status would be.
another possible extension to mailcap (which i hesitate to suggest since
it's something of a hack) comes from the metamail documentation:
The "command" field is any UNIX command ("cat %s" in the above example),
and is used to specify the interpreter for the given type of message. It
will be passed to the shell via the system(3) facility. Semicolons and
backslashes within the command must be quoted with backslashes. If the
command contains "%s", those two characters will be replaced by the name of
a file that contains the body of the message. If it contains "%t', those
two characters will be replaced by the content-type field, including the
subtype, if any. (That is, if the content-type was "image/pbm;
opt1=something-else", then "%t" would be replaced by "image/pbm".) If the
command field contains "%{" followed by a parameter name and a closing "}",
then all those characters will be replaced by the value of the named
parameter, if any, from the Content-type header. Thus, in the previous
example, "%{opt1}" will be replaced by "something-else". Finally, if the
command contains "\%", those two characters will be replaced by a single %
character. (In fact, the backslash can be used to quote any character,
including itself.)
so the server can send
Content-type: application/x-dvi; base_url=http://whatever
this can be picked up under X via
application/x-dvi; xhdvi %s %{base_url}
the above environment variable option is more logical, since after all
the base url really is metainformation and not content-type.
but either way will work in the short term.
> Until such things get standardized, we would be happy to implement
> any suggestion you would make in the next release of SpiderWoman,
> for the purpose of demonstration.
another thing we could use in a demo version is a reasonable gui for
POSTing files to forms. (another one of my fruitless lobbying efforts for
over a year -- no one seems to accept that www can be used for two
way communication to servers, though it's built into protocol).
give us a window into which we can drag multiple file icons (just
like the nextmail compose window) and assemble it into some standard
format (nextmail, mime, or compressed tar, ...) and pipe to the server
via a form submit. then we've long known how to process it at this end.
> Do you know about the WebSteb mailing list that discuss standardization of
> WWW aware apps for NEXTSTEP? This could be a good forum to develop
> these ideas. The WebStep initiative, launched by Rohit Khare at
> Caltech is also supposed to contribute to the W3O standards.
probably someone mentioned it, but generally i'm far too busy to be
involved in any of these things. i'll try to get someone here to track
that list. (isn't this the one that programs circular Location: redirects?)
> Let me know if you would like to receive information about the
> latest version of SpiderWoman. The publicly available release is
> severely outdated.
sure send it along. i've checked http://sente.epfl.ch/~swoman/
from time to time, but it's been static.
pg