Trekkie.lha          biz/dbase  887K+Star Trek Database, V2.15final Data V2.1
HTTPlister.lha       biz/dopus   15K+View AMINET RECENT in lister +download f
dvbcontrolfont.lha   comm/misc  355K+Many Fonts for DVBControl
orion.lzh            comm/misc   18K+Amiga<->IBM-PC data transfer program.
HTTPResume_Fre.lha   comm/www     3K+French localization for HTTPResume v1.6
Lynx282dev24.lha     comm/www   884K+Fast WWW browser -Colors and more now-
Grapevine10a.lha     demo/mag   760K+LSD Grapevine diskmag, issue 10 (1/3)
Grapevine10b.lha     demo/mag   779K+LSD Grapevine diskmag, issue 10 (2/3)
Grapevine10c.lha     demo/mag   733K+LSD Grapevine diskmag, issue 10 (3/3)
Grapevine13a.lha     demo/mag   751K+LSD Grapevine diskmag, issue 13 (1/3)
Grapevine13b.lha     demo/mag   822K+LSD Grapevine diskmag, issue 13 (2/3)
Grapevine13c.lha     demo/mag   782K+LSD Grapevine diskmag, issue 13 (3/3)
Grapevine14a.lha     demo/mag   754K+LSD Grapevine diskmag, issue 14 (1/3)
Grapevine14b.lha     demo/mag   790K+LSD Grapevine diskmag, issue 14 (2/3)
Grapevine14c.lha     demo/mag   797K+LSD Grapevine diskmag, issue 14 (3/3)
Grapevine15b.lha     demo/mag   751K+LSD Grapevine diskmag, issue 15 (2/3)
Grapevine15c.lha     demo/mag   761K+LSD Grapevine diskmag, issue 15 (3/3)
gui4cli.lha          dev/gui    536K+Easy, event driven GUI language - V3.7
FloppyFlux.lha       disk/bakup  25K+V1.1, Backup your old floppy disks to HD
ACNews10.lha         docs/mags   56K+E-zine focused on Amiga News: #10-Apr 99
die.lha              game/2play 651K+THE BEST 2player duel
VAxen.lha            game/shoot 372K+VAxen - Hexen Amiga Port v0.8 (PPC)
Mp2anim.lha          gfx/conv   270K+Converts & scales mpeg animations to ami
Forging.lha          gfx/ifx      3K+FXForge filters
comeBreed.lha        mods/hardc  79K+A good gabber PT module by Breed
fkBreed.lha          mods/hardc  20K+A good speedcore PT module by Breed
MSX-SIDcollect.lha   mods/sets  267K+MSX-SIDcollection
classicBreed.lha     mods/techn 177K+A good dance PT module by Breed
danceBreed.lha       mods/techn  93K+A bad dance PT module by Breed
bodyBreed.lha        mods/tranc 104K+A good trance PT module by Breed
floorBreed.lha       mods/tranc  92K+A good trance PT module by Breed
godBreed.lha         mods/tranc  69K+A good trance PT module by Breed
MiraMP3GUI11.lha     mus/misc    43K+GUI for 8hz, MusicIN & Pegase
SoundBoxKey.lha      mus/misc     1K+Free Keyfile, Soundfile multi-format con
MYST_Data_9.lha      mus/play   593K+YM2149 soundchip emulator Musics Data #9
CUFAlley.lha         pix/art    327K+Alley - WB Background
CUFEva01.lha         pix/art    312K+Prototype EVA 01 - WB Background
CUFGandalf.lha       pix/art    216K+Gandalf's Journey - WB Background
CUFA3000.lha         pix/back   262K+Amiga 3000 - WB Background
CUFGroovy.lha        pix/back   385K+Groovy  - WB Background
CUFMasses.lha        pix/back   297K+Amiga For The Masses - WB Background
CUFRei.lha           pix/back   352K+Rei Ayanami (Spring) - WB Background
bzip2.lha            util/arc   241K+File compressor for 68k/PowerUp/WarpOS
NewStuff.lha         util/boot   35K+Get instant access to new files! (v1.0)
NoWBStartup2.lha     util/boot   14K+Stop WBStartUp progs from running
IdentifyDev.lha      util/libs   73K+Identify hardware and more, ListExp (V11
IdentifyUsr.lha      util/libs  122K+Identify hardware and more, ListExp (V11
PalmLink.lha         util/libs   93K+Connect Amiga with 3Com Palm PDA (V1.2)
PubScrnTools.lha     util/misc   35K+Public Screen Tools (src included)
adda_src.lha         util/wb      1K+Source for AddAssign

soundamirx.lha       comm/irc     2K+Sound AmIRX Script For AmIRC/WildIRC
iris.lha             comm/mail  283K+Email client (SMTP/POP3) V1.9
IrisUpdate.lha       comm/mail   46K+Update Iris V1.8 to V1.9
YAM2P7_PL.lha        comm/mail   45K+YAM2P7 - PL version by Spider
YAMsp.lha            comm/mail   95K+YAM Spanish Documentation v2.0 7.2
AGM33c_full.lha      comm/misc  492K+FULL VERSION of full-blown German Teleko
FTS10_full.lha       comm/misc  124K+Remote control program for the AMIGA
SafeEdit.lha         comm/thor    3K+Prevents posting unedited messages with 
BoingTransf.lha      comm/www   129K+24bit/256 colors BoingBall Ibrowse-trans
SP9.lha              demo/mag   1.7M+Seenpoint #9 by Scoopex [March/99]
StatsFuncs.lha       dev/basic   41K+Big update, much easier to find stuff.
GAPLib.lha           dev/c      232K+Comprehensive Genetic Algorithm Programm
AIOV23.lha           docs/mags  225K+Amiga Information Online, Issue 23 (Apri
Mags_txt_index.lha   docs/mags   25K+TEXT indices of magazine articles
amigotchyfull.lha    game/misc  453K+Free full version of the first *REAL* vi
Demolicious.lha      game/misc   53K+Quake demo editor
fu_psv_main-1.lha    game/misc   12M+Football management game (full version)
xtru.lha             game/patch  88K+Track installer and manager for XTreme R
Mpeg2anim13.lha      gfx/conv   606K+Converts MPEG animations into ANIM files
Mpeg2Anim13.lha      gfx/conv   606K+Converts MPEG animations into ANIM files
VE-Extras.lha        gfx/edit   125K+Visual Eng. - External files v1.66
Show.lha             gfx/show   696K+Cybergfx only picture viewer (040+PPC) V
c1581.lha            misc/emu    49K+A c1581 filesystem for Amiga (3.5") driv
C64Gfx.lha           misc/emu   327K+C64 graphics format conversion package
uae-app_015.lha      misc/emu    39K+UAE-ADF Mount+Unmount Workbench-Interfac
Sadley.lha           mods/melod 270K+Spoochy's 19th OctaMed mod.
Fantasy_Lacy.lha     mods/misc  244K+Spoochy's 18th OctaMed mod.
mvp_0038.lha         mods/mvp   2.4M+MoPlayaz - intelligent logicaleness EP
WF7_MVS-Block1.mpg   pix/anim   506K+Wildfire 7 - MVS Example - Block
WF7_MVS-Block2.mpg   pix/anim   506K+Wildfire 7 - MVS Example - Shadow Block
DMS2HD1_5.lha        util/arc    47K+Unpacks DMS archives to HD v1.5
AHelp1_2.lha         util/cdity  80K+The ultimate HELP: manager v1.2
FileExtract.lha      util/cli     8K+Extract part of a file into a new file
Ordering_v1.17.lha   util/dir   320K+Powerful directory utility for OS 2.04
AtLast.lha           util/misc    7K+At last! Reboot from WB's Quit menu!
LC2.lha              util/misc  151K+Aussie Lotto checker/database.
ResetRun.lha         util/misc    3K+Resets your computer and runs a given pr
FWCalendar.lha       util/rexx   58K+THE calendar creator for FW & Pagestream
RememberTime.lha     util/time    2K+Util for Amigas without battery clock
Starter.lha          util/wb     25K+Run programs from a file requester!

KOSH [Kommunity Orientated Software Hardware]

Weekly Summary

Week Commencing: 17th April 1999

Number: 017

Mailing List: kosh-general

In the mailing list this week, the following items were discussed. Please do
not email the scribe regarding any of these topics, it is not his job to answer
these questions but merely to report  the topics of conversation. If you have
any queries about this summary, please email ben@kosh.net, stating the Summary
Number, and Mailing List Name, and he will try to answer your queries.

a)

Subject: Eye tracking cameras

Summary of debate: It would be forward thinking of KOSH to support eye tracking
                   cameras natively, rather than as an added kludge to certain
                   existing systems.

                   See: http://www.visioncs.com/ re: a commercial gaze tracker.

                   It was suggested that on screen a mouse pointer could still
                   be required so that you would know where you are looking at.
                   However, such a system may not work as if the cursor isn't
                   always exactly where you're looking, you'd start to follow
                   it with your eyes and create a runaway feedback loop.

                   Bite-on switches or ear muscle tension systems were offered
                   as an alternative to blinking to select icons on a screen,
                   as the eyes must blink naturally and this could cause
                   confusion.

                   It was stated that brainwave reading is progressing fast, a
                   "click" can already be read. This yet again shows that there
                   are many alternative ways to controlling input to a
                   computer.

                   Could the Artificial Muscle Research Institute help with the
                   realization of haptic display gloves? The idea suggested was
                   for a shoulder length glove that allowed the user to feel
                   virtual holographic objects, push them around, sculpt
                   computer graphics like clay and have a virtual keyboard.
                   See the AMRIs URL at: http://www.unm.edu/~amri/index.html

                   (Scribe's note: I've decided to take the liberty of
                   mentioning directly here for people who may only read the
                   summaries and not the whole General ML that all of the above
                   does not mean the end of the computer mouse - if you want to
                   use one with KOSH it will of course be perfectly possible to
                   do so).


b)

Subject: KOSH design standards

Summary of debate: It was stated and restated that design standards for KOSH
                   are to be open - viewable and usable by all.

                   It was asked what common standards are people going to have
                   to adhere to in designing items for KOSH?

                   Joel Newkirk resuggested a "Standards Working Group".

                   Suggested standards to determine initially were
                   communications, media and hardware. For these APIs will be
                   needed.

                   A generic image class could be developed and then formats
                   like GIF, PNG, BMP, IFF/ILBM etc fall out as subclasses -
                   perhaps with restrictions which may need thinking about.

                   Suggested five basic types of standards (Sound, Image,
                   Movie, Text, Settings) could possibly make up most normal
                   formats needed. Further, could we make a quick
                   design/requirement of these five?

                   It was commented that would these types hold up in current
                   usage? For example, the whole of a magazine could be one
                   file - including bitmaps, structured images, fonts, masks,
                   text layout etc. The large structure is on top of the
                   individual elements, but all the parts are functionally
                   linked and not just separate items.

                   The method of transmitting the instructions for creating
                   data needs to be considered. The example given was that of a
                   MIDI file which requires an interpreter with local knowledge
                   as opposed to a a WAV which contains the data itself.

                   Suitable low level objects might be n-dimensional arrays of
                   integers. At the next level up, these might be labelled as
                   representing sound samples, stock market trends, bitmaps or
                   GUI windows etc.


c)

Subject KOSH Hybrids

Summary of debate: Perhaps it could be possible to combine object types to
                   make hybrids, eg: image + sound = movie.

                   An image can be flat 2D, a 3D array or X by Y by RGB; a
                   multilayered Photoshop/ArtEffect projects or many other
                   occurrences. A database is equally complex - with this is
                   mind the "hybrid" is the norm.

                   Would the IFF list of forms be of any help for the hybrids?

                   It was then stated by the original proposer of hybrids that
                   perhaps it would be better to make (for example) a Movie
                   basic class and then let it use the Sound and Image basic
                   classes.


d)

Subject: Small tools for KOSH and cross application compatibility

Summary of debate: Suggested that Unix like commands like WC should be
                   implemented in KOSH. Further by nature of the fact that KOSH
                   uses objects and not files, the wordprocessed object would
                   listen to wordprocessor methods when the wordprocessor loads
                   it. If it was made a subclass of "ASCII file" (or Unicode or
                   UTF-8 etc) you could  process the ASCII representation
                   (or Unicode or UTF-8) in a KOSH version of "WC" or "Emacs".


e)

Subject: KOSH compatibility with the wider world

Summary of debate: There will definitely be some sort of "customs agent" for
                   this. This may well be complicated or perhaps there would be
                   several of them.

                   This would build an appropriate file object for any items
                   downloaded or loaded from hard media (floppy, CD etc). An
                   API as part of this would be a standardized place for things
                   like virus checkers to be added.

                   A browser could even be very simple. It needs a simple
                   display engine and the ability to interpret the web and
                   translate it into objects. These objects (those five
                   mentioned above and the specialised subclasses) then display
                   themselves. This would make "plug-ins" redundant as once a
                   class for that type of media was on a system it could
                   display or use it.

                   The Emulator Object could be a part of the chain of
                   subclasses from the base classes. This could save a lot of
                   special cases which would promote simplicity.

                   Suggested that the emulation could be split into common
                   parts and into the instruction sets of the processors in
                   question. To do this the emulation of, for example movie
                   formats, could be put into the movies chain of subclassing.
                   The emulation should be last in the chain and should scan
                   the different plug-ins (or equivalent) available and use
                   them.

f)

Subject: Designing KOSH APIs

Summary of debate: It was mentioned that APIs will be needed for a number of
                   things described above. KOSHans could work on these now as
                   it is not necessary to know the final binary form of an
                   object in order to work out the methods and data structures
                   that can optimally manage such a thing.

                   The design of a serial port was mentioned. See:
                   http://www.sei.cmu.edu, search for "product line
                   architecture" which goes into the question of what you can
                   have in common between designs (eg: sending and receiving
                   data) and what you need to vary for each special occasion
                   (eg: you can't do the same thing to the serial port as you
                   can to your USB port).

                   Suggested we establish some clearinghouse for API
                   recommendations - perhaps a working group could oversee
                   that.


g)

Subject: KOSH Object Manager

Summary of debate: Dave Haynie has said that he hope to get a paper on this
                   done by June or July. After this a prototypical
                   demonstration Object Manager can be hacked together.

                   Then we want the floodgates loosed and all of the pieces of
                   the OS to be developed.


h)

Subject: KOSH Driver factory

Summary of debate: It was proposed that a "driver factory" that could enable
                   its users to choose the appropriate "standard" class to work
                   from, and make various associations and connections quickly
                   and simply, and then write any necessary code to support
                   additions or modifications.

                   This would make developing for KOSH easier and thus hardware
                   developers would be more likely to develop for the system.
                   The "driver factory" could be part of a developer support
                   package or program.


i)

Subject: Furthering KOSH

Summary of debate: Fleecy Moss has suggested that we need to move to a more
                   concentrated stage in KOSH where we can proceed without
                   distraction. To this end he has suggested two things:

                   1) A formal documentation and version control system so we
                   can all work together in a remote environment,

                   2) KOSH will start as a formal specification of its
                   individual parts and its environment. Once the
                   specifications are out, anyone with a mind can produce the
                   individual pieces themselves. What is required is a formal
                   specification language to define the interfaces.

                   Fleecy further detailed other things that are required:

                   a) One of the things to be identified is the Basic Sea
                   Services Set, the minimal services provided by the cybersea
                   that are required for the sea to exist.

                   b) The services pages also contains a lot of other services.
                   A write up for each of them listing what we would like them
                   to do would be a first stage to moving forwards.

                   c) BOSS - Basic OS Services - this entity is the gateway
                   between the logical sea and the physical matrix beneath.
                   someone to have a go at defining the Basic OS Services
                   required by the sea.

                   d) A development strategy - perhaps this should be phased,
                   with the early phases seeing us implement KOSH as an
                   application.
                   The BOSS can be a thin server, mapping KOSH to an underlying
                   kernal, which is suggested as being POSIX compliant, running
                   on an x86 - this enables us to use Linux and all of its
                   tools and x86s, which are the dominant computer, and the one
                   most ppl have access to at this time.
                   Whilst KOSH is supposed to be hardware independent, the
                   implementation of a neutral distribution format will have to
                   wait until a later phase.
                   Suggested that were possible KOSH should be defined and
                   implemented using XML. We need more information and a
                   coherent plan, positives and negatives.

                   e) We can do KOSH correctly, in which it is logically
                   correct with full integrity, or we can tie it to hardware
                   considerations, for speed. Fleecy states that speed will
                   always increase, and he would rather get it right at the
                   beginning for the sake of speed rather than to hack and path
                   later on because we went for speed. Elegance through
                   simplicity, but elegance requires coherence and not
                   compromise.


j)

Subject: Questions on the future of KOSH

Summary of debate: The following important questions were raised:
                   How is the KOSH website coming along?
                   How is KOSH as a whole coming along?
                   To this end, which papers are written, how far have they
                   come, can they be reviewed?
                   Where can those who are doing nothing but writing to the
                   mailing lists help?


k)

Subject: Documentation and version control system

Summary of debate: Gabriel J. Hauber has volunteered to look at what has been
                   done so far in building the above and try to get it
                   completed in a reasonable time.


l)

Subject: Anyone know where Rudi is?

Summary of debate: If anyone has current contact details for Rudi please could
                   they post them to the General Mailing List.


m)

Subject: F-CPU

Summary of debate: An interesting project called F-CPU can be seen at:
                   http://f-cpu.tux.org/original/


n)

Subject: Query on the survey content

Summary of debate: The Surveying Working Group is unsure whether to ask people
                   whether alien file format support is desired or not. The
                   problem with asking is that (from a survey of the Surveying
                   WG it would seem!) half the people think it would worry
                   people that we looked like we weren't sure about it, while
                   the other half think it would reassure people that we were
                   thinking of it.

                   The Surveying WG does not want to just declare "we are
                   supporting alien file formats" as this should be left to a
                   survey. Therein lies the problem.