| Previous Chapter: Appendix - Architecture |
This part of the manual deals with various special issues that did not fit in the normal flow of text in the general user manual sections, but may still be of some interest to a category of users.
HTTP Server and persistent sessions
Since an HTTP session is stateless, it was necessary to implement a mechanism that would allow persistent sessions and persistent script execution. The Ovrimos mechanism for persistent sessions does not depend on user-side cookies, since these make security-sensitive users nervous. Thus, a novel mechanism was implemented, which is based on the propagation back and forth of a unique identifier for each session..
As an example, we present a special URL, /alpha, that makes reference at some later time to another URL, /beta.
| CLIENT AGENT | HTTP SERVER |
| GET /alpha |
|
|
| A session number is
returned to the client program |
|
302 Redirect to
/sessionAC34/alpha |
| GET /sessionAC34/alpha |
|
|
|
|
HTTP Server responds for alpha | |
| A link to /beta is requested
GET /beta |
|
|
|
|
302 Redirect to
/sessionAC34/beta |
|
| Get /sessionAC34/beta |
|
|
|
|
HTTP Server responds for beta |
The Unicode version 1.1 and ISO/IEC 10646-1:1993 jointly define a 16 bit character set, UCS-2, which encompasses most of the world's writing systems. Instead of using only one byte (8 bit), the Unicode uses 2 bytes (16 bits), thus enabling a uniform, easy encoding of any language (even Japanese, Korean and Chinese).
Two data types, unicode char and unicode varchar are used to allow data definition of Unicode data.
Example of a table with unicode data:
create table universal (
latin_word varchar(30),
japanese_word unicode varchar(30)
);
The unicode characters may be inserted in two different ways:
1. In the sqlapp4 client program, prefixed by the character u,
e.g.
insert ... values (..., u'This is a Unicode character \u3A18 in
the middle of ASCII text',...)
The \u marks the beginning of the unicode character. This, of course,
is not an easy way to insert unicode characters.
2. In Microsoft Explorer 4 browser, using UTF-8, users may insert the
string in the SQL Terminal, prefixed by the character w, e.g.
insert ... values (..., w'<unicode characters>', ...);
Unfortunately, some browsers do not send form data in Unicode, but send
8-bit ASCII, encoded in UTF-8, having a puzzling effect to users who might
perceive this as a malfunctioning of our Unicode support. Sometimes, the
browser displays Unicode characters incorrectly in input fields but sends
them correctly to the database and some other times it doesn't even do
that.
Nevertheless, displaying Unicode characters is as easy as displaying
ASCII characters in any browser.
Parameter CHARSET is set for each new database created. CHARSET is used
by the browser to take the necessary actions for displaying characters.
Default is ISO-8859-1 (Latin character set).
Users wishing to represent Unicode characters must use the UTF-8 character
set.
When a charset other than UTF-8 is used, then:
All times are stored internally in UTC (also called GMT, Greenwich
Meridian Time).
However, users often prefer to see the times in their local time zone,
therefore a few modifications have been made, not to the way the times
are stored, but to the way they are presented.
When a session starts, the default time zone is the time zone of the
Server. (Note! Not the local time zone of the machine where the user works,
but the machine where Ovrimos resides).
If the default time zone is not convenient, users may modify their
time zone by the Set Time Zone command. This does not affect the internal
representation of times and timestamps. It only affects the way information
will be displayed for the user. More on this subject on Set
Time Zone.
Since the default FreeBSD kernel lacks System V IPC support, FreeBSD users may have to rebuild their system kernel, enabling both SYSVSEM and SYSVSHM. In short:
For more information, users may consult the document of FreeBSD in handbook.htm
| Previous Chapter: Appendix - Architecture |