-
Notifications
You must be signed in to change notification settings - Fork 0
/
TODO
99 lines (79 loc) · 4.83 KB
/
TODO
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
List of things that should be done:
[ ([email protected]) I have implemented this in <database_query ...> ]
* Generic database query mechanism.
[ ([email protected]) I have implemented this via PATH_TRANSLATIONS ]
* Script Aliases and Translations. Allow (via configuration file)
random string transformations such as "/ais/" -> "/foo/cgi-bin/ais/".
[ ([email protected]) I have implemented this, and tested it by hacking
cookies into the NCSA server. Now running on www.datawave.net. ]
* Test and verify sessions using build-page with Netscape server
and client. I'm sure this currently does not work.
[ ([email protected]) Rewritten. Now works as advertised. ]
* Test and verify correctness of polygon test in src/imagemap.c.
It occurs to me that I may have coded the initial triangle
similarity algorithm using the Cartesian coordinate system,
instead of the fucked up inverted Y coordinate system that idiot
graphic systems use. If this is the case, the algorithm should
produce YES for the vertically and horizontally flipped mirror
images of a given polygon.
* Write shared memory functions for the session database.
Alternatively, make the session database have a TCP/IP interface,
so that multiple machines can share users. This, or something
like it, will probably be necessary in the future.
[ ([email protected]) This is implemented through the use of
package-to-alist and alist-to-package. See macros/session-substs.mhtml. ]
* Implement direct installation of a session with data. The idea
is that a user session state could be saved in a permanent
database indefinitely, and then restored when the user signs back
on. This could be done by creating a new session, but it would
be simpler and more elegant to have a <session-resume SID>
command. Think of it as saving your Emacs state across logins.
[ ([email protected]) Implemented in elisp/mhtml.el ]
* Design and implement Emacs Meta-HTML mode.
[ ([email protected]) I have implemented user-defined macros and substs. ]
* Implement user-defined macros. Since each invocation of
build-page is a single run of a program, the user-defined macros
will have to be read for every invocation. This may be too
expensive. On the other hand, it is a necessity for implementing
a Meta-HTML Web server.
* Implement an on-the-fly byte-compiler. This would prefer (for
example) *.mhtmlc over *.mhtml if the .mhtmlc file were newer.
If the .mhtmlc file was older, or non-existant, the interpreter
could lock the .mhtmlc file, byte compile the .mhtml file, and
then return the page. Subsequent calls would get the .mhtmlc
file.
* Along the lines of byte-compiling, we could compile Meta-HTML
files into C programs. Because of the way the interpreter is
implemented, open coding is an easy and simple win here. I may
pursue this before anything else, since that may obviate the need
to ever write a CGI program in C again.
[ ([email protected], [email protected]) Implemented for MSQL ]
* Consider the implementation of a genuine relational database as
an integrated part of Meta-HTML. The existing kludge works for
simple cases, such as my toy Rolodex applet, but is meaningless
in the real world of database manipulations. About the most you
can do with this is to save a user session state in a permanent
fashion.
[ ([email protected]) Implemented in examples/mastermind ]
* An implementation of the MasterMind game where there are five hidden
pegs, each of which can be of various colors, and the contestant
tries to guess what the order and colors of the pegs are in a
limited number of moves. The response for each guess is the number
of pegs guessed right, and the number in the correct position.
* A central repository for the full documentation of the GNU project.
This could work either by reading the Info documents, or by
running the documents through Makeinfo, or Texi2HTML.
* A System Administration page, from which many common functions
could be run, including ps, DNS management functions, user
management functions, etc.
* Dynamically changing billboard advertising; something that could
be placed at the top of any page. This would display an
advertisement chosen at random from some known list of ads.
The frequency of a particular ad's appearance could be a function
of how much money the advertiser paid.
* On-line credit verification: You type in your credit card number,
someone's social security number, and you get their loan-worthiness
or whatever, from TRW, digitally signed. Or your own credit report.
* Reservations and ticketing systems, especially airlines, but the
system could work for anything.
* Real-estate on line.