NoSD - A Background Paper

NEXTSTEP and OpenStep Software Database
An electronic database for NEXTSTEP and OpenStep software

Version 1.0 28 Nov 1995

I. Preface

This project was set up to overcome the deficit on reliable information about NEXTSTEP Software. NeXT itself does only supply information about commercial products, and their written broschures are rather outdated. On the other hand, new software is entering the market every day, some commercial, some public domain. 
A further difficulty emerges from the rising number of supported platforms, which often may lead to the situation that a certain product might be availble only to certain platforms, thereby narrowing its usability. Furthermore, it seems to be of concern for many potential NEXTSTEP users to have a sufficient number of programs available. Common prejudice tells that there are no programs existing for NEXTSTEP. This project would like to prove to the contrary.

It is aimed at a total survey of "soft" products for NEXTSTEP which are, will be, or have been available for NEXTSTEP, comprising programs, mission critical projects, patches, system extensions, fonts, drivers, tools, etc. It shall also include hardware drivers which have accumulated throughout a NEXTSTEP version cycle and were incorporated by NeXT into a newer version of NEXTSTEP, as well as demos which have been included with NEXTSTEP (like chess or Mandelbrot), but once were independent programs.

This is not a small goal, though. Therefore, we would appreciate input from the NeXT community. We would like to invite NEXTSTEP developers to supply us with descriptions of their products and we are also looking for volunteers to take over part of the describing work. Finally, we hope that we can make the database available on several FTP servers throughout the world.

2. Description of the NoSD database 

2.1. General concepts

In principle, the NoSD is set up as a collection of plain text (ASCII) files, each containing the information about one software object (program, patch, font etc.). 

The files have a specific structure which allows automatic generation, maintainance, and access. The physical location of NoSD is at the "Peanuts" FTP server of the University of Munich, Germany, European Union, in the directory ftp://peanuts.leo.org/pub/comp/platforms/next/00INFO/NoSD.

To provide as great a flexibility as possible, several methods for submitting new files are provided, as well as numereous ways to access the information contained in the NoSD files. 
For submitting a new entry, a World Wide Web server is provided at the University of Munich which can be accessed at http://peanuts.leo.org/nosd/. For those without access to WWW, we have also developped The_NoSD_Submitter.app, a little application with a nice NEXTSTEP GUI which  helps in creating entries to NoSD. Information entered with the help of The_NoSD_Submitter can either be sent to us automatically by e-mail or be stored on floppy for mailing through normal snail mail. 
To request information from NoSD, it is possible to contact the WWW server.  Of course, it goes without saying that the individual files in NoSD can also be copied via anonymious ftp, as any file from the FTP server. For a non internet dependent distribution, NoSD is also available on floppy, and even in a printed (well, photo copied) version, which will be published quarterly when an apropriate number of entries to NoSD exist.

2.2. Structure of the NoSD files

The files are named according to their  "Title" (see below), followed by the extension *.nosd.form". Spaces (" ") in the title which are used in naming NEXTSTEP programs will be converted to Underscore ("_"). 

Each NoSD file  contains the description of a single object. Objects can be any kind of "soft" ware running with NEXTSTEP, i.e. programs, program bundles, system extensions (preference modules, inspectors, services), drivers, fonts, images (pictures, charts, icons etc.), sounds, video sequences and others. 
Any record should describe as few objects as reasonable. For example, a progam bundle should of course have a file for the bundle, but also entries for the individual programs constituting the bundle. On the other hand,  a font collection with a plurality of different fonts should preferably be described in a single entry instead of one entry for every font.

All data elements  in a file, except the "Object type", have been defined as "attribute/value" pairs which can generally be described as:

	@<data element name>=<data element value>

The object type will be used to define the kind of NoSD file. Each of the files starts with the key  word @Begin(NX_SOFT) and ends with @End(NX_SOFT).
The following table will describe the data element names and, if any restrictions apply, the possible data element values.
It should be noted that due to the fact that the "@" sign is used as formatting information, as a rule, any "@" in the description must appear as "@@". The conversion is done automatically by the WWW server and The_NoSD_Submitter. However, when writing a NoSD entry by hand, this rule has to be obeyed.

The order in which the data elements are described hereafter is the same as in the actual NoSD files.

		
	Category:			The nomination of the category to which the object 						belongs is based on a five letter code, wherein the first 						two letters mark the broad range, the other three further 						specifiy the category. For a complete list of possible 						categories, write e-mail to 						nosd-info@informatik.uni-muenchen.de with the subject 						"categories". 	Since it is very difficult to cover the hole 						range of existing  or possible software, we would like to 						get further input  and improvements from the community. 						Should an object  belong to several categories, those 						should  be given in descending order of appliance. Up to 						five 	categories may be included in this data field. If, for 
						a certain object, none of the categories should 
						seem to fit, a proposal for a new category 
						should be filed to the adress given in paragraph 2.4 of 						this paper. 

	Title:				Title of the product. This field should normally 
						contain the name of the "*.app","*.pkg", ".config" etc.  file 						of  the object. The extension itself is not part of the title. If 						a bundle of several products 
						is to be described in the template, the name 
						for the bundle as commercialized should be given.

	Author:Name:   		Description/contact information about the
						authors/creators of the object.  For commercial objects, 						the company name should appear here.

	Author:Work-Phone:	Phone number of author or company.

	Author:Work-Fax:		Fax number of author or company.

	Author:Work-Postal:	Adress of author or company as normally (country 						dependend) formated. Should also contain the country.

	Author:Email:			e-mail adress of author or company.

	Record-Last-Modified:USER:
						Contact information about person last
						modifying this file. e-mail will be sufficient.

	Record-Last-Modified:Date:
						The date the last time this file was
						modified.

        Record-Last-Verified:USER:
			        		Contact information of person or group
			        		last verifying that this file was
			        		accurate.

        Record-Last-Verified:Date:
			        		The date the last time this file was
			        		verified.

	Version:				A version designator for the object.

	Requirements:		Any requirements for the use of the
						object. A free text description of any
						hardware/software requirements necessary
						to use the object. Also, if the Kanji version of NEXTSTEP 						is required, this should be noted here.

	Description:			Description of the object.  If this file is to describe a 						bundle of  objects, a reference to the products 						comprising the bundle should be made (including their 
						ID numbers). If the object is part of another object, 
						the description should start with "PART OF:" 
						followed by the name of the bundle as given 
						in the bundle fiel.

	Short-Description: 		Short description with not more than 30 characters.

The following Architecture fields are intended to characterize which versions of a program, running on what platforms, are available. Below, the platform denominators as presently defined will be described. However, when using the programs for submitting entries automatically, buttom fields for marking the relevant versions will be provided.

	Architecture:NEXTSTEP: 	The NEXTSTEP versions which are available. They 						are separated by kommas and spaces.
						Valid denominators are:

						motorola: 	NeXT computers
						intel: 		IBM compatible computers
						hp: 			HP-Workstations or  compatibles
						sparc: 		Sparc compliant computers
						powerpc: 	PreP compliant systems
						mips: 		MIPS based computers
						decalpha: 	Digital computers with alpha CPU
						apple: 		Apple PowerPC
						source: 		source code available/included

	Architecture:Openstep: 	The available OpenStep versions. These versions are given as pairs of values, separated by "/" slash, the first value thereof indicating the operating system the OpenStep version runs on, the second one indicating the hardware. Example: osf1/decalpha is for designating an Openstep software running on Digitals alpha machines with OSF/1 operating system. The pairs are separated by kommas and spaces.
						Valid denominators for operating systems are:

						solaris: Sun Solaris
						sunos: Sun  OS (UNIX)
						hpux: HP Model 9000 UNIX
						osf1: DEC Alpha UNIX
						sco: Santa Cruz Operation Open Desktop
						linux: Public Domain UNIX
						43bsd: Another Public Domain UNIX
						44bsd: Yet another Public Domain UNIX
						irix: Silicon Graphics UNIX
						windowsnt: well, yes
						os2: IBM OS/2
						ultrix: DEC MIPS UNIX
						dgux: Data General UNIX
						auspex: Auspex UNIX
						source: source code available

						Valid denominators for hardware: see above under 						NEXTSTEP; and:
						hp8: HP server Modell 800
						aviion: Aviion server (Data General, Motorola 88000)
						decstation: DEC workstation with MIPS CPU
						auspex: Auspex server

	Architecture:GNUStep: See above for denominators.The available GNUStep versions. These versions are given as pairs of values, separated by "/" slash, the first value thereof indicating the operating system the GNUStep version runs on, the second one indicating the hardware. Example: linux/intel is for designating a GNUStep software running on IBM PCs with the Linux operating system. The pairs are separated by kommas and spaces.
							
	Architecture:Others:	See above for denominators. This is for NEXTSTEP/OpenStep specific Software not running under NS/OS environment (like Netinfo).
	
	Publication-Status:		Current publication status of object
					
						The following denominators are valid:
						available: product is available
						beta: product is currently tested
						planed: planed release
						obsolete: product is still available, but will not run 
						with current versions of NEXTSTEP
						defunct: product is no longer available. However, 
						one may still be able to get a copy from somewhere. 
						If not all version have the same publication status, the  						status of the most improved version should be given.

	Copyright:Type: 		The copyright type of the object. 

						Valid denominators are:
						commercial: Commercial product
						publicdomain: Freely distributable, no charge
						freeware: free, but copyrighted
						shareware: free for testing, has to be lizensed
						gnuware: under the GNU copyleft policy.

	Copyright:statement:	The copyright statement. Any additional
						information on the copying policy may be
						included. Also, pricing can be included, if necessary, in 						several currencies. Furthermore, it should be indicated 						whether support for the software will be given by the 						developper.

	Creation-Date:		The creation date for the object.

	Keywords:			Appropriate keywords for this object.

	

2.3 Data formats  

 To facilitate the machine readability of certain data elements, the
   following syntax applies.

   1) All electronic mail (e-mail) addresses should be as defined in RFC
      822, Section 6. Names and comments may be included in the Email address.

      For example:

	   "John Doe" <jd@ftp.bar.org>
		   or
	   jd@ftp.bar.org

      are valid Email addresses. 

   2) All hostnames are to be given as Fully Qualified Domain Names as
      defined in RFC 1034, Section 3.

      For example "foo.bar.com"

   3) All host IP addresses are given in "dotted-quad" (or
      "dotted-decimal") notation. 

      For example, "127.0.0.1"

   4) All numeric values are in decimal unless otherwise stated.

   5) Dates must be given as defined in RFC 822, Section 5.1 and
      modified in RFC 1123, Section 5.2.14 [7]:

     date-time   =  [ day "," ] date time        ; dd mm yy
                                                 ;  hh:mm:ss zzz

     day         =  "Mon"  / "Tue" /  "Wed"  / "Thu"
                 /  "Fri"  / "Sat" /  "Sun"

     date        = date = 1*2DIGIT month 2*4DIGIT ; day month year
                                                  ;  e.g. 20 Jun 82

     month       =  "Jan"  /  "Feb" /  "Mar"  /  "Apr"
                 /  "May"  /  "Jun" /  "Jul"  /  "Aug"
                 /  "Sep"  /  "Oct" /  "Nov"  /  "Dec"

      For example the string "Sat, 18 Jun 93" is a valid
      date.

     6) All text shall be in NEXTSTEP ASCII, allowing the use of 
         special signs like french accents or german umlauts.

    7) "whitespace" is defined as one or more blank (octal 40) and/or tab
      (octal 11) ASCII characters.

   8) All telephone numbers are to be given as a minimum in full with
      country and routing codes without separators. The number should be
      given assuming someone calling internationally. The number given in
      the local convention may optionally be specified.

      For example,

      Telephone: 1 514 875 8189  (+1-514-875-8611)

      or

      Telephone: 44 71 732 8011

2.4. Submissions to the NoSD

Three different methods for submissing descriptions of software will be available:

1. Via WorldWideWeb

The WWW server is accessible at http://peanuts.leo.org/nosd. After invoking the command "New description", the submitter will be presented a formsheet for inputting the above information. Since a large amount of information may be entered, the formsheet is split up into several sections.

2. By using The_NoSD_Submitter.app, 

a program specifically designed for preparing entries to NoSD. The_NoSD_Submitter.app allows to send an entry submission by e-mail or to store on floppy for normal mailing
When using The_NoSD_Submitter.app, the submitter will be presented several windows having separate groups of entry fields which he/she should fill out. The_NoSD_Submitter.app wil then create a *.nosd.form file. The submitter may then choose to send the intermediate file directly by email, to the adressee nosd@informatik.uni-muenchen.de or to store it on floppy for mailing it to the adress below or for further editing.

3. By sending a floppy with files in the NoSD format. This is not recommended, though accepted.

Entries can be submitted in any of the three languages English, German and French. However, they will be translated to English prior to publication in the NoSD.
The submitted records will be edited, i.e. controlled for their clarity, typing errors and formal compliance. 

Dr. Thyl Engelhardt
Taimerhofstr. 18
81927 Muenchen
Germany
Fon: +49 89 9578100
Fax: +49 89 9296265
e-mail: me@thyls.muc.de or engelh@informatk.uni-muenchen.de

This is also the adress for sending files when going the hard way and creating NoSD files directly, e.g. with a text editor.

After the files have been sent to us, members of the NoSD group will do the following:
1. check the *.nosd.form files for formal compliance, conciseness etc.
2. Check whether the files might be a doublette of a file already contained in NoSD
3. Check whether such a file might be an update
4. Finally, put the file into the NoSD subdirectory

3. Distribution of the NoSD

It is intended to have several distribution means for the information collected in the NoSD. Some will be available right from the start, others will require greater effort and are therefore on schedule for later.

3.1 Some information is available through electronic mail. Send an email to nosd-info@informatik.uni-muenchen.de with one of the following subjects:
"info"		to get an introduction to NoSD
"background" 	for a deeper insight into the concepts and plans behind NoSD
"entries"		for a current list of all described software
"submitter"	for a manual of The_NoSD_Submitter, our program for preparing entries into the NoSD database (by e-mail of floppy). (.rtfd)
"categories"	for a recent list of codes for software categories (.rtf)
"guide"		list of frequent errors / guideline for formal checks (.rtf)
"thedead"	list of developpers we could not identify/reach
The_NoSD_Submitter can be copied via ftp from the ftp server of the university of Munich.

The list "entries" will contain in alphabetical order the following fields of all NoSD files:
Title (in alphabetical order), author.name, first Category, Short description, Copyright.Type. This list is updated daily by a script extracting the above information from the NoSD files.

3.2. Distribution by World Wide Web

The NoSD WWW server is accessible at http://peanuts.leo.org/nosd. A menu driven dialog will facilitate access to the NoSD.  As a particular service, this WWW server will also be able to directly send software which was previously selected in a search operation if this software is available on the well sorted FTP server of the university of Munich. This comprises public domain software as well as unlisenced and demo commercial software.

3.3. Distribution through anonymious FTP

It is of course possible to copy all files contained in the NoSD subdirectory ftp://ftp.informatik.uni-muenchen.de/pub/comp/platforms/next/00info/NoSD/ from the Munich FTP server. For this type of access, you will need to know the file names of the entries you want to get . 

3.4. Distribution on Floppy
	
After we have gathered sufficient information (later this year), the NoSD will also be distibuted on floppy for those without internet access. The floppy will be in NEXTSTEP format and contain all entries and an index for use with the Digital Librarian. To get the latest version, send a $5 bill or a bill of equivalent value to the adress in paragraph 2.4.
	
3.5. Distribution in printed form

An edited version of the database content will be available as an RTF file and in printed form. Beside the descriptions contained in the database, ordered by categories, it will also have a short editorial. The printed version will be on DIN A5 sheets of double side-printed, recycled paper and may be orderd at the adress given in paragraph 2.4. The price for the printed version depends on the sheet number. Ask for information.

4. Examples

4.1 Example 1: driver for BusLogic BT445S, public domain.

@Begin(NX_SOFT)
@Category=drmsa
@Title=BusLogicFamily
@Author:Name=Tomas Hurka,  Ondrej Cada
@Author:Work-Phone=n.n.
@Author:Work-Fax=n.n.
@Author:Work-Postal=Hukatronic, Kankovskeho 8, 18200 Praha 8,Czech Republic
@Author:Email=tom@@hukatronic.cz 
@Record-Last-Modified:USER=Thyl Engelhardt <Thyl.Engelhardt@@muc.de>
@Record-Last-Modified:Date=29 Dec 1994
@Record-Last-Verified:USER=Thyl Engelhardt <Thyl_Engelhardt@@muc.de>
@Record-Last-Verified:Date=29 Dec 1994
@Version=1.13
@Requirements=BusLogic BT445S or BT747 F-SCSI-2 adapter
@Description=supports BT445S (VL bus), BT747 (EISA), 32 bit DMA adressing. The driver was tested and works with these version of firmware on BT445S: 3.31C, 3.36, 3.37. The driver was tested and works with these version of firmware on BT747S: 3.37.
@Short-Description=driver for BT445S, BT747, 32 bit
@Architecture:NEXTSTEP=intel
@Architecture:OpenStep=
@Architecture:GNUstep=
@Architecture:Others=
@Publication-Status=available
@Copyright:Type=shareware
@Copyright:statement=The BusLogicFamily driver for NSFIP is a shareware. You can freely distribute without changing or removing any parts of the package. If you found the driver reliable, please, register the driver. Price: $40 
@Creation-Date=01 Aug 1994
@Keywords=BT445S, BT747, BusLogic, SCSI, SCSI adapter
@End(NX_SOFT)

4.2 Archie, a public domain program

@Begin(NX_SOFT)
@Category=nwser
@Title=Archie
@Author:Name=Scott Stark
@Author:Work-Phone=
@Author:Work-Fax=
@Author:Work-Postal=
@Author:Email=starksm@@genesis.mcs.com
@Record-Last-Modified:USER=Thyl Engelhardt <Thyl_Engelhardt@@muc.de>
@Record-Last-Modified:Date=15 Jan 1995
@Record-Last-Verified:USER=Thyl Engelhardt <Thyl_Engelhardt@@muc.de>
@Record-Last-Verified:Date=15 Jan 1995
@Version=2.15
@Requirements=internet access
@Description=Archie 2.09a is a 3.0 NeXTSTEP analog of George Ferguson's
Xwindow based archie client.  It provides all of its functionality withthe niceties of the NeXTSTEP interface, as well as documents and interactive ftp sessions. The program is based on the query.[ch], ftplib.[ch], and Prospero library subset provided with George's 2.0 beta version of Xarchie.
@Short-Description=archie client
@Architecture:NEXTSTEP=motorola
@Architecture:Openstep=
@Architecture:GNUstep=
@Architecture:Others=
@Publication-Status=available
@Copyright:Type=publicdomain
@Copyright:statement=
@Creation-Date=18 Jun 1994
@Keywords=archie, documents, internet service
@End(NX_SOFT)

5. Members

The NoSD group presently are (in alphabetical order):

Christian Baur  <cbaur@informatik.uni-muenchen.de>   (ftp-link)       
Thyl Engelhardt  <me@thyls.muc.de>  (coordination, public relation, documentation)
Marc  Guenther <yoda@cis.uni-muenchen.de>                  
Michael  Karneim  <karneim@informatik.uni-muenchen.de>  (WWW server)      
Sven Meûfeldt <messfeld@informatik.uni-muenchen.de> (The_NoSD_Submitter)
Bernhard Scholz <boerny@informatik.tu-muenchen.de> (idx Converter)
Patrick Stein  <jolly@cis.uni-muenchen.de>   (e-mail server)                
Dominik Westner  < westner@informatik.uni-muenchen.de>   (e-mail server)