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:)