Rohit Khare wrote:
-> Any support for an RFC to spec:
-> dwrite WebStep LinkColor "NXColor for links"
-> dwrite WebStep PostLinkColor "NXColor for traversed links"
Yes - I definitely support for an RFC to spec standard dwrites
BUT - "WebStep" shouldn't supplant GLOBAL for cross-application
specifications. Since GLOBALs should be managed by a Preferences
module, that should allow the standard in-app fetches of
configured globals to override in-app default values on the
first run of a new app which only writes values under its own
name to the defaults database.
-> dwrite WebStep URLOpener "String of valid service accepting
-> NXAscii or URIPb"
-> dwrite WebStep <Scheme>Opener "Valid service to open a particular
-> scheme"
-> [Such as Gopher, WAIS, etc]
Now, here I question the use of a dwrite. The list CAN become
enormous (needlessly degrading other apps using the database). I
really think that we should follow NeXT's lead here with their
~/.NeXT/suffixes3_1.<arch>.wmd
using ~/.AppInfo/<appname>/url_openers.<arch>.table, until
Workspace itself incorporates a standard URL opener database
under ~/.NeXT/
Since the suffixes3_1.<arch>.wmd file IS in fact a .table file
in format (though not QUITE logically so), and MiscKit supports
parsing of that format, it seems that that would provide only
two places to look.
Perhaps, though, an ~/.AppInfo/WebStep directory could be part of
the rfc for storage of COMMON URL OPENER values and other .table
files found needed cross-application. That, of course, precludes
the NAMING of an application as WebStep.app. It would leave two
(and likely ultimately three) places to look for a configuration
table -
~/.AppInfo/WebStep/url_openers.<arch>.table - cross-app
~/.AppInfo/<appname>/url_openers.<arch>.table - app specific
~/.NeXT/<somename>.<arch>.wmd - if Workspace supports it.
AND
~/.AppInfo/WebStep/url_editors.<arch>.table - cross-app
~/.AppInfo/<appname>/url_editors.<arch>.table - app specific
~/.NeXT/<somename>.<arch>.wmd - if Workspace supports it.
The suffixes3_1.<arch>.wmd format is simple...
<suffix> = ( <full-path-to-opener-executable> [,<icon-name>] );
<suffix> is the file extension WITHOUT leading dot, nor
wildcards.
equal-sign, parentheses, and trailing semicolon and newline are
literal
,<icon-name> is optional, with a built-in being used if missing,
as I understand it....
obtainable with +[NXImage findImageNamed:] (maybe)
but definitely with -[Application getIconForFile:]
workspace protocol request.
EXAMPLES of suffixes3_1.m68k.wmd...
tgz = (/LocalApps/Opener.app/Opener, docGz);
PS = (/LocalApps/BBFig.app/BBFig);
addresses = (/usr/lib/NextStep/Workspace.app/WM.app/
addresses.bundle/addresses, addressBookSupportFile);
"draw~" = (/NextDeveloper/Demos/Draw.app/Draw, drawdoctilde);
I propose that the url_openers.<arch>.table should be easily
created from parsing a standard "mime.types" file, and correlating it
with the suffixes3_1.<arch>.wmd to generate a new table structure and
related file.
".table" formated mime.types file would be optional, in the same
directory if present, and named mime.types.table, with the following
format:
application = {
postscript = ( ai, eps, ps );
rtf = rtf;
x-tex = tex;
x-troff = ( t, tr, roff );
zip = zip;
};
audio = {
basic = ( au, snd );
x-aiff = ( aif, aiff, aifc );
x-wav = wav;
}
image = {
gif = gif;
ief = ief;
jpeg = (jpeg, jpg, jpe );
tiff = ( tiff, tif );
x-xbitmap = xbm;
x-xpixmap = xpm;
}
text = {
html = ( html, htmld, HTM, HTD );
x-html3 = ( html, htmld );
plain = txt;
richtext = rtx;
tab-separated-values = tsv;
x-setext = etx;
}
video = {
mpeg = ( mpeg, mpg, mpe );
quicktime = ( qt, mov );
x-msvideo = avi;
x-sgi-movie = movie;
}
This makes cross-referencing an existing Workspace default opener
almost trivial, certainly cut-and-dried, based on an incoming or
referenced MIME type. Look up the MIME type, use that as an index
for the opener or editor table, depending upon the type of app,
and/or operating state. A locally supported extension can be FORCED
for a distant image with a known MIME type but unknown extension.
Having this mechanism available in place of ONLY using the
WorkspaceRequest protocol -getInfoForFile:application:type: to fetch
the suffixes3_1.<arch>.wmd entry for a given extension gives several
advantages...
1. Don't have to already have the file locally to see
if we have an appropriate opener for it, nor kludge
around with a fake file, as has been the "stock" answer.
2. We can maintain a secondary "editor" table for editing
applications.
Parsing the ~/.NeXT/services/.cache isn't quite as trivial :-)
to test filterable type pairs.
To answer such items as the text/x-html3 type, if no applications
are on board to handle a newer MIME type, then the FIRST lookup
would fail, so it should largely prevent handing a file to a
"opener" that could handle the file by extension, but not by later
MIME type and the content it represents. This actually extends
the current Workspace handling capacities in respect to the
broader environment represented by the Web.
Bruce
+-+
Bruce Gingery Total System Software Cheyenne, WY USA
NEXT IN LINE magazine staff technical writer
Bruce Gingery <bgingery@Wyoming.COM>
Bruce Gingery <bruce@TotSysSoft.com>
Multimedia: NeXTmail(tm) preferred MIME-mail welcome