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.