KOSH [Kommunity Orientated Software Hardware]

Weekly Summary

Week Commencing: 13th March 1999

Number: 012

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: Alternative filesystem mechanics

Summary of debate: Part of the feature set for the filesystem "SFS" is that it
                   supports a "run-time defragmenter" that defragments the
                   drive when the user isn't accessing it. Still in development
                   but take a look at the following if interested:
                   http://www.xs4all.nl/~hjohn/SFS/features.htm

                   There is a similar tool under development for PFS2


b)

Subject: File locations

Summary of debate: If the end user wants to be able to keep their files in
                   locations not originally designed for, eg: applications in
                   the applications area then they should be able to do so.


c)

Subject: Sets

Summary of debate: A collection of files/objects could be termed a set. Sets
                   can contain subsets. Two sets can also contain common
                   objects without one being a subset of another. Folders and
                   drawers as terms lack this ability of multiplicity.

                   Soft sets would contain only references to objects. Hard
                   sets would contain the objects themselves.


d)

Subject: Moving around a GUI

Summary of debate: At the moment most GUI's are designed so that you move
                   around them vertically and then horizontally (or vice
                   versa). As a result moving windows, text, pictures etc. in a
                   fluid and accurate diagonal manner can be haphazard at best.
                   For example: resizing windows in 2 plains at once is OK, but
                   after that you are left with a vertical and a horizontal
                   scroll bar and nothing that combines both (except the new
                   track wheel mice - but these have their problems).

                   Therefore it would be nice if KOSH could have diagonal
                   movement built in as standard in an intuitive way.


e)

Subject: New keys on keyboards

Summary of debate: It would be nice if KOSHkeyboards had cut, copy and paste
                   keys in intuitive positions. However you should be able to
                   define your own clipboard keys so adding these three may not
                   be necessary. If we did add these keys they would need to be
                   placed in the main area of the keyboard and not off to one
                   side (eg: near the keypad) as accessing them becomes slower.

f)

Subject: Abstraction and Backing up data

Summary of debate: Scribe's note: this is a subject that I have summarised in
                   depth as it is central to a number of concerns that people
                   have expressed about the object sea.

                   KOSH will fully abstract physical and logical devices in a
                   comprehensive and easy-to-live-with manner. Therefore it
                   will be possible to locate all animations, text objects,
                   application objects, etc individually (eg: .jpg) or by
                   group (eg: all picture types etc) that are present on the
                   system irrespective of where they are located.

                   There is no relationship between the layout of the
                   filesystem as presented to the user and the physical
                   location of the files on a disk.

                   However there should still be a way to find all data
                   relating to a particular object or objects. This could be
                   one of the many entries in the object "database". Therefore
                   an option to display the system as per the conventional
                   currently used directory tree system should also be included
                   as this could be of use when wanting to do things like data
                   backups.

                   However the user should not need to see this. The backup
                   tool perhaps does but it can present the information to you
                   in whatever way you like.

                   Backup tools would probably take a frozen object and
                   compress it (if not already) and store it on the chosen
                   backup media, and note the pertinent information in some
                   index object it maintains of the backup.

                   Backup tools don't need to work directly with the storage
                   system on the drive, just with the objects themselves. It is
                   unlikely that people would often want to perform a
                   block-by-block backup of their files.

                   With an object sea, you throw your work into the sea. To
                   enable you to find it again, it has one or several strings
                   attached to it. When you need it you can just pull in the
                   right string until your creation comes up to the surface. A
                   natural worry that this creates is that the descriptive
                   strings could get broken and objects could therefore be
                   theoretically lost in the sea.

                   Therefore objects in the object sea will not float in an
                   arbitrary way. The objects will be ordered, even if they can
                   have links all over the place.

                   When sending an object to another KOSH machine the class
                   object and associated binding would be understood. however
                   when passing this same object (eg: a JPEG file) to a Linux
                   or Windows machine, they don't know KOSH object structures or
                   class bindings. Further, "JPEG" has a fairly precise
                   definition as a byte-stream. When sending this out to other
                   systems, just that JPEG stream would be wanted. Likewise
                   when importing: a JPEG (again as an example) from another
                   system should be inserted into a JPEG object.

                   Having the ability to add compression, cryptification or other
                   services to the objectsystem is a very good idea.

g)

Subject: Java Serialization

Summary of debate: See: http://www.javasoft.com - In Java there is something
                   called serialization which provides an easy way to implement
                   loads and saves of data in an ArrayList (from the Java API).
                   This could be the same with the Object Sea except that load
                   and save are replaced with freeze/unfreeze.


h)

Subject: Engineering Jobs at Amiga (in San Jose)

Summary of debate: See: http://www.amiga.de or the post forwarded to the ML by
                   Paul May dated 13/03/99, title as per the above subject
                   for information about positions with Amiga.


i)

Subject: Status of AROS

Summary of debate: Paul May has also forwarded a statement on AROS and where it
                   is currently at to the ML, dated 13/03/99, title: [TA] AROS
                   Statement (fwd).


j)

Subject: Icons (continued)

Summary of debate: Do we want fixed size icons which must occupy a specific
                   square or do we go for the Amiga approach which is more
                   flexible but potentially untidier and harder to handle?


k)

Subject: Force feedback input devices

Summary of debate: The idea to have force feedback devices such as a mouse was
                   suggested. This could (for example) let the user feel
                   scrollbars as channels, resizing windows as pulling elastic
                   and selecting icons becoming heavier the more you picked up.


l)

Subject: Mouse-Responsive Speech in a GUI

Summary of debate: As the mouse (or other control device) moves around the
                   desktop a voice could quietly tell the user the name
                   associated with each icon that is passed over, or some other
                   sound, word, or phrase specific to it. This then provides
                   aural confirmation of selection for those who may benefit
                   from such a feature. The same type of aural presentation
                   could equally as an option be implemented for menus and
                   controls within an application. The same applies to context
                   menus in web browsers.


m)

Subject: Heat dissipation in KOSHboxes (continuing "Waterproofing KOSH")

Summary of debate: Two links recommended regarding cooling chips are:
                   http://www.kryotech.com/ and
                   http://www.totalpc.net/hardware/renegade/
                   Kryotech manufactures cooling cases for PCs that use a
                   refrigerating base that runs through a heatsink that you can
                   then affix to your CPU in place of a standard heatsink.

                   The best solution to overheating would be to use low power
                   components and some sensible power management system that
                   can power down unused parts of the system.

                   As for radio interference as previously mentioned, the way
                   to solve this is with shielding which converts radiation
                   back into heat which can then be dissipated via some inbuilt
                   system.

                   The orientation of cards to allow for unfanned convective
                   currents to be optimised could be important. Orientating
                   cards on a vertical plane would not hinder heat
                   dissipation.

                   We must ensure that any KOSHbox that is produced can compete
                   in the general marketplace and therefore special cases and
                   heat dissipation units may increase the cost and reduce
                   sales potential when put next to an average PC. Therefore
                   apart from passive design points (eg: orientating cards
                   vertically) there may be little we can do initially to
                   improve designs.



n)

Subject: Virtual memory in newer NetBSD systems

Summary of debate: See: http://www.ccrc.wustl.edu/pub/chuck/tech/uvm/ for some
                   technical documents on the above.


o)

Subject: Compiling for the Object Sea

Summary of debate: How far would existing compilers need to be rewritten to
                   take account of the new object system when taking into
                   account the fact that programs tend to save data as
                   separate files?

                   A set of functions in the OO filesystem would allow existing
                   applications to be directed to use the new system and not
                   rely on traditional methods of saving. A method would be
                   needed to map the old style files onto the OO filespace.

                   It was stated that this would have nothing to do with
                   compilers as most languages have I/O as some kind of library
                   routine. Allowing for some functions being rewritten there
                   should be no problem.


p)

Subject: RAM disks

Summary of debate: Implementing a RAM: disk aka Amiga-style but designed to
                   work with virtual memory so that the data would be held on
                   disk but not placed in memory. This could be a better way to
                   handle things than temporary files in Windows.

                   Perhaps if everything is conceptually in RAM (including
                   contents of physical disks). Some systems use this and it
                   would building an OO system with persistent objects.

                   There could actually be a (small?) application which does
                   about the same thing as a RAM: disk.


q)

Subject: Task masking

Summary of debate: Could we set up a system where, via a quick option, certain
                   running tasks are suspended and hidden according to user
                   settings and (optionally) another one that's been frozen in
                   the background gets re-activated and set as the current
                   running application?

                   Hotkeys could accommodate this.


r)

Subject: Use of computers by those with disabilities

Summary of debate: See:
     http://www.newsunlimited.co.uk/The_Paper/Weekly/Story/0,3605,30692,00.html
                   which is relevant to the above subject particularly as KOSH
                   aims to enable accessibility for all.


s)

Subject: Speed and thousands of files

Summary of debate: In a traditional filesystem organising several thousand
                   files into several directories with several subdirectories
                   allows for a relatively fast search and locate for an
                   individual file. With the Object Sea references to objects
                   will similarly allow fast access - most likely faster
                   if a directory class optimised for large numbers of files
                   was created.


t)

Subject: Printing of objects

Summary of debate: Objects could be made to include the details to be able to
                   print themselves if text (or show themselves if pictures -
                   or both if either etc). This would remove concerns about
                   having the correct viewer/whatever to be able to use the
                   object. Could Amiga-style datatypes be used for this?


u)

Subject: Computer knit-wear

Summary of debate: See: http://wearables.stanford.edu/ for (what one scribe-e
                   describes as) a "combined pocket computer and hand warmer".


v)

Subject: Userinterface Working Group

Summary of debate: Timo Suoranta wants to work on user interfaces. For this he
                   would like a mailing list and a working group set up. Timo
                   details that this would be started by making one version of
                   the user interface with a limited C++ object model. Then when
                   the KOSH object model is available this can be rewritten or
                   translated. The first version would run on top of X.

                   Timo will look at some existing user interfaces which have
                   free source code and see if this can be utilised. See:
                   http://www.fsai.fh-trier.de/~schmitzj/Xclasses/ which could
                   be relevant.

                   It turns out that Xclasses had some building trouble, but
                   another promising toolkit could be: http://fltk.easysw.com
                   which Timo built on his NetBSD system.


w)

Subject: Disadvantages of the Windows interface (again)

Summary of debate: Greg says the URL quoted last time should have been:
                   http://www.iarchitect.com/msoft.htm - that little "l" makes
                   all the difference:)