Text preview for : 19770815_Comments_On_Janus_Applications_Software_Functional_Specification.pdf part of xerox 19770815 Comments On Janus Applications Software Functional Specification xerox sdd memos_1977 19770815_Comments_On_Janus_Applications_Software_Functional_Specification.pdf
Back to : 19770815_Comments_On_Janu | Home
Inter-Office IVlemorandum
To Distribution Date 15 Allgust 77
From Jim White (for Bob Metcalfe) Location Palo Alto
Subject Comments on Janus Allplications Organization SDD/SD/CS
Soft ware Functional Speci fication
XEtOX SDD ARCHIVES
)(EROX I have read and understood
Pages _________To _________
Reviewer Date
Filed on: -# of Pages
----
Ref .:1 Ti>DD- "!>otJ,
This memo responds to the request for written internal comments from SOD/SD on Janus
Release 1, Applications Software Functional Specification, Version 2, dated 22 July 77.
Must Change
Filing, Printing, Document Transfer
Addressing Workstations
The user should be able to address non-Janus workstations in the same way he addresses
other Janus workstations to which he is connected by the Xerox Wire: by name, rather than
by description. Janus should provide a directory facility by which the user (e.g., at system
configuration time) can name the workstations with which he interacts and declare their
types (e.g., IDM MCSTII), locations (e.g., telephone number), and default conversion
parameters. Once a workstation has been so declared, the user should be allowed to
designate it as the source or destination for a document transfer simply by giving its name;
Janus should assume responsibility for retrieving the workstation's type and location from
the directory. (For RS-232-C connections without AutoDial, Janus could then even remind
the user of the telephone number to be dialed.)
Careful, early attention mllst be given in OIS to how objects (e.g., files and lIsers, as well as
workstations) are named within the office environment. Janus-l naming conventions
should be ones that can be extended naturally to support the more complex office
information systems that will follow it.
Must be Discussed
Filing, Printing, Document Transfer
Specifying Document Transfer Participants
The final paragraph on page 5 of "Manual Doclllllent Transfer" slates that one Janus
workstation can orchestrate the transfer of a document between two other workstations only
if one is another Janus workstation connected by the Xerox Wire and the other is a
workstation connected by an RS-232-C interface. This restriction seems arbitrary. Surely
both source and destination can be Janlls workstations connected to the orchestrator by the
Xerox Wire. Also, cannol both be workstations (whether Janus or non-Janus) connected to
the orchestrator by RS-232-C interfaces, with the orchestrator's workstation serving as
middleman?
Comments on Janus Applications Software Functional Specification 2
Naming and Storing Incoming Documents
Rather than automatically assign names like "lYfAIL-101l6-22:05-Smith" to incoming
documents, allow the user to name each document himself as he removes it from his
mailbox. Even if newly arrived documents are placed on the user's documelll disk, they
should not be placed in his file drawer except under his control. The name of the sender
and the c1ate and time of delivery, of course, are important pieces of information which
should be accessible to the lIser, but let's not construct document names from them. (The
namihgscheme proposed in the functional specification is not even sufficient to guarantee
uniqueness, since two documents from the same uscr could easily arrive within a minute of
one another.) (Is there any possibility that incoming documents could be placed on the
system dtsk until processed by the user?)
The functional specification also states that the recipient of a document will be shown the
name under which the document was stored by the sender. It would seem more appropriate
and useful for the sender, as part of the send operation, to supply a document title or subject
line to be communicated to the recipient.
Converting Documents Between Formats
Who has responsibility for describing in detail the document format conversions to be
supported by Janus-I? The last paragraph on page 1 of "Manual Document Transfer" places
this information in the Communications Functional Specification, yet it is not clear that
sllch high-level matters fall within the domain of communication.
Dedicating System Elements to Printing and Distributing Documents
The "Printing" and "Automatic Document Transfer" sections of the functional specification
provide that documents are always printed and distributed by the user's workstation. Janlls-
1 seems to provide no assistance to the customer who wishes to decicate workstations to one
or both of these functions. Is remote printing, for example, to be supported in the initial
release of the system?
At very least, the llser should be able to manually transfer a document to another
workstation and initiate its printing from there. This requires that the printer page of the
document option sheet travel with the document from one workstation to another. In a
more sophisticated implementation, remote printing would be directly supported by Janus,
and the printer window would report the status of the remote operation.
Suggestions for Improvement
Text Editing
Preserving the Edited File from Session to Session
To preserve his edits, must the lIser explicitly store his file before leaving the editor (as
Bravo requires him to do), or does his document survive on the desktop from one session to
another? The user should not lose his work if, for example, a hardware or software failure
interrupts his session.
Reformatting Automatically After Edits
Many users will find it a nuisance to have to explicitly reformat a paragraph after deleting
characters from it. If preserving the hole caused by a deletion is an important capability
(no justification for it is given in the functional specification), the lIser should be given the
option of automatic reformatting as well.
XEROX
PRIVATE
DATA
Comments on Janus Applications Software Functiollal Specification 3
Providing an Undo Facility
The ability to remove the effects of the previolls operation, as provided by Bravo's undo
command, is a lIseful feature.
Filing, Printing, Document Transfer
Inferring and Transmilling Distribution Lists
Documents (e.g" inter-office memoranda) often contain their distribution lists. It would
seem imPortant, therefore, for Janus to be able to infer a document's distribution list from
the document itself, yet Janus requires that distribution lists be typed by the user or stored
as records in other documents. Why not allow a mock in which Janus determines the
distribution list, for example, by looking for a "workstation Address" field in the document
being sent or by searching for "To:" at the head of the document or "c:" at its tail?
It is also important to be able to transmit a distribution list with the document whose
delivery it controls. Among other things, this permits implementation of forward and
ansyver functions like those present in the Tenex MSG subsystem.
Also, can one distribution list contain a pointer to another? That is, can one group of
workstations be defined in terms of other, previously dcfined groups?
Verifying the Sender's Identity in a Document Transfer
What guarantees that the call received by the destination workstation in a manual document
transfer (especially a workstation equipped with an RS-232-C connection with AutoAnswer)
is from the intended party? The eighth paragraph on page 4 of "Manual Document
Transfer" alludes to an exchange of user names, but this area seems to need clarification.
Recognizing Disk Types Automatically
It is presumably some Pilot facility that underlies the document transfer facility's ability to
automatically distinguish between Janus, Troy, and System 6 floppy disks. Is this really
feasible and ,veIl thought out?
Being More Specific Than "In Use"
The document statlls indicator on the cover page of the document option sheet flags as "In
Use" a document qucued for transfer or printing. Why not indicate more specifically why
the document is unavailable to the user (e.g., "Being Printed", "Awaiting Printing", "Being
Transferred")? It also might be desireable to flag documents that originated at non-Janus
workstations, were not converted to Janus format, and hence cannot be edited.
Ordering the Print Queue
The document filing system automatically sorts the contents of the file drawer on the basis
of criteria specified by the user. Similar sorting facilities might be offered in connection
with the print queue. For example, a user might wish his print requests executed in
increasing order of document size.
Defining Priviledged Users
Priviledged llsers are alluded to at several points in the functional specification (e.g., in the
first paragraph on page 4 of "Document Filing System"), but never defined. More should be
said about them. A login procedure is also alluded to in connection with the AutoUscr field
described 011 page 8 of "Field Definition", but is not described in the functional
specification. It seems clear that more attention needs to be given to the development of a
model of the OIS user.
XEROX
PRIVATE
DATA
Comments on Janus Applications Software Functional Specification 4
Handling Graphics on the Jason Printer
The functional specification describes the manual font switch procedure for the Jason
printer. How is graphical data such as transfer symbols handled. if at all?
c: Bob Metcalfe
Wendell Shultz
Jerry Szelong
Tim Townsend
Info: SODISOleS
ft'\~:"f'\ XEROX
?~Q~~j PRIVATE
~lJV DATA