From owner-freebsd-doc Thu May 23 21:45:52 1996 Return-Path: owner-doc Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id VAA16380 for doc-outgoing; Thu, 23 May 1996 21:45:52 -0700 (PDT) Received: from pop01.ny.us.ibm.net (pop01.ny.us.ibm.net [165.87.194.251]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id VAA16371 for ; Thu, 23 May 1996 21:45:49 -0700 (PDT) Received: (from mail@localhost) by pop01.ny.us.ibm.net (8.6.9/8.6.9) id EAA203934; Fri, 24 May 1996 04:45:07 GMT Message-Id: <199605240445.EAA203934@pop01.ny.us.ibm.net> From: "Francisco Reyes" To: "John Fieber" Cc: "FreeBSD doc Mailing list" Date: Fri, 24 May 96 00:36:05 -0400 Reply-To: "Francisco Reyes" Priority: Normal X-Mailer: Francisco Reyes's Registered PMMail 1.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Hardware compatibility documentation Sender: owner-doc@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Thu, 23 May 1996 08:24:12 -0500 (EST), John Fieber wrote: >On Thu, 23 May 1996, Francisco Reyes wrote: > >> I am thinking to start helping first with PC hardware compatibility > We need to clearly define the scope of the section and the >format for the entries. I personally think the nature of this >section is ill defined at the moment > > Intel > 486 > 33 A couple of comments.. What I had though to do was to build a database. Even if it was ASCII lines. I prefer to have one line per item. SGML is not database friendly. Once we have an ASCII file with one entry per item then writing a program to convert that to SGML is a one shot deal. The other advantage of this approach is that we can easily change the format if the need arised. I also think that it is better to start collecting the data and then consider how we want to present it. After all it will take a while to get a good list of hardware. We may also be able to make a better decition of what to do with the data once we see what kind of data people are sending. Perhaps few people may know something we ask for and we may end up not asking for it. My suggestion as to what to collect with a suggested format. #hardware#computer:make,model,cpu,cpu speed #hardware#video:make,model,bus type,resolution #hardware#harddrive:make,model,HD type #hardware#soundcard:make,model,options #hardware#cdrom:make,model,bus type #hardware#monitor:make,model,size,resolution samples: #hardware#computer:Austin,486-33VLI,Intel,33 #hardware#video:?,Speedstar,ISA,3 #hardware#harddrive:Maxtor,850MB,IDE #hardware#soundcard:?,Sound Blaster,- #hardware#cdrom:Plextor,4X,SCSI #hardware#monitor:MAG,?,15,3 Notes/Comments: The categories and details are only suggestions we could have more or less. Notice that I have used "-", "?", and the number 3. These could represent "not applicable", "don't know" and a code respectively. Codes could be used for bus types (ie 1=SCSI, 2=IDE,etc..."), monitor sizes, resolutions, etc... The long header #computer# is again just a suggestion. Anything that would rarely appear in a regular message or as part of a source file, or any file for that matter would be fine. The reason for this is that I would like to have the capability to receive this information in a file together with other lines not related to the hardware compatibility documentation. This could be useful for instance when sending messages to anyone working in the upkeeping of the "database" or anyone doing some tests could get some lines by email and process it. Where do we go from here? Let's get this started!