Lexer version 0.22 (05.04.99)
ADDED: The attribute HTTP-EQUIV
ADDED: The attribute CONTENT
ADDED: The attribute BORDER
ADDED: The attribute COLSPAN
ADDED: The attribute SIZE
ADDED: The element TR
FIXED: Tags that are split over several lines
       (caused the duplication bug)
FIXED: The attribute TYPE
CHANGED: Internal changes, v0.22 is
 smaller than the previous version

AFM3.lha             comm/mail   43K+AFM3 - Aminet Ftp by Email (MUI+YAM)
GetAllHTML.lha       comm/tcp    15K+Auto-download/check entire web sites! (v
GnS-Away.lha         demo/aga   1.7M+*WINNER* Demo at TRiP'99 by GENESIS.
pjz_tg99.lha         demo/slide 1.0M+Partyslide and report fresh from TG99.
trp-as1.lha          demo/sound 2.1M+Australian Style #1 by Trip
AsmPro.lha           dev/asm    159K+Asm-Pro V1.16 mc680x0 macro assembler
AFM2_Source.lha      dev/basic   10K+AFM2_01 Source Code for BB2
CNKI.lha             dev/basic   34K+Converts a brush/animbrush to .CNK file
AutodocV132.lha      dev/misc    46K+A really neat autodoc viewer v1.32 (OS3.
AIOPetro.lha         docs/anno   13K+Petro Tyschtschenko interviewed in AIO i
EmailAIO.txt         docs/anno    1K+Get AIO magazine each month via email, t
BAB5_Gde.lha         docs/hyper  38K+Babylon 5 Episode Guide (115a)
ClassesGuide.lha     docs/lists  10K+A Guide of Amiga custom BOOPSI classes. 
Aakt0499HTML.lha     docs/mags  232K+AMIGA aktuell - German infotainment maga
Amiga4ever6.lha      docs/mags  857K+Issue 6 of the German Freeware Mag
JAFEB.lha            docs/misc  243K+JUST-AMiGA mailing list msgs for all of 
jamar.lha            docs/misc  166K+JUST-AMiGA mailing list msgs for all of 
BomberBlaster.lha    game/2play 290K+Work in progress demo of great Super Bom
SpodRacer.lha        game/2play 1.6M+Full version of this Destruction Derby i
DC2Lvl-Jewels5.lha   game/data  524K+99 new Levels for Diamond Caves II
gm_backdrop10.lha    game/data  113K+Replacement Backdrops for F1GP
gm_backdrop11.lha    game/data  181K+Replacement Backdrops for F1GP
gm_cart1999.lha      game/data   15K+Cart Datafile for F1GP
FaYoh.lha            game/jump  435K+Full version of a GianaSisters-style pla
VE-gausedge.lha      gfx/edit     2K+Visual Eng. - Gaussian edge v1.55
VE-gausfeather.lha   gfx/edit     1K+Visual Eng. - Gaussian feather v1.21
VE-logotexture.lha   gfx/edit     2K+Visual Eng. - Logo texture v1.15
VE-primcolors.lha    gfx/edit     2K+Visual Eng. - Primary colors v1.81
VE-shadow.lha        gfx/edit     4K+Visual Eng. - Shadow v3.19
ay-colly6.lha        mods/chip   50K+Collection of the best AY musics for DT.
ballfish.lha         mods/jorma  60K+Ballfish by Pekka Pou (Elektro, from Sun
meeting.lha          mods/jorma 232K+Meeting by Vesuri (House, from Ulsteri)
Freedom_rmx.lha      mods/melod  82K+Spoochy's 13th OctaMed mod.
Maiga_rmx.lha        mods/melod  87K+Spoochy's 15th OctaMed mod.
gethood.lha          mods/piano 144K+Spoochy's 14th OctaMed mod.
tvns-badmix.lha      mods/techn 285K+Spoochy's 17th OctaMed mod.
Denoman.lha          mods/tranc 126K+Spoochy's 12th OctaMed mod.
Traminglo.lha        mods/tranc 170K+Spoochy's 16th OctaMed mod.
bsb.lha              pix/art     38K+An Anti-BSB Pic
RPG-Icons.lha        pix/art     32K+154 Icons painted for never released RPG
Klingons.jpg         pix/mark   265K+Bird-of-Prey, Vor'Cha and Negh'Var
QuesWB.lha           pix/wb      73K+My new style workbench grab :)
RM4mat.lha           text/misc   10K+Remove format code in GB texts (chinese)
CheckX.lha           util/arc    33K+V1.56 Check for Archives/Packers/Viruses
ViNCEd.lha           util/shell 709K+ViNCEd, the final CON: solution. ^Z, TAB
ViNCUpdate.lha       util/shell 212K+ViNCEd, the final CON: solution. ^Z, TAB
StringSnip.lha       util/sys    12K+Much better editing features in string g
KaiClock.lha         util/time   64K+KaiClock V2.2. A clock for WB

svconvert.lha        biz/dopus    6K+Convert pictures using SViewII and Dopus

Amplifier_Dopu.lha   biz/dopus    0K+Load MPEG AUDIO files into Amplifier wit
DeliTracker2_D.lha   biz/dopus    1K+Load Modules into DeliTracker2 with Dopu
VE-addspaceb.lha     gfx/edit     2K+Visual Eng. - Add space B v1.03
SvII-2.lha           gfx/misc   209K+SViewII V8.30 (31.3.99) - Part 2/8
SvII-8.lha           gfx/misc   211K+SViewII V8.30 (31.3.99) - Part 8/8 (opti
houseBreed.lha       mods/house  40K+A happy house PT module by Breed
lns30jungleEp1.lha   mods/jungl 376K+JungleEp p1 - Devils delegate
lns30jungleEp2.lha   mods/jungl 330K+JungleEp p2 - a lovely bomb
lnsR4_diarrea.lha    mods/jungl 372K+Summer diarrea - jungle
A2-MRb338.lha        mods/misc   30K+Astrosyn`2 - Rebirth-338 music compo ent
astralBreed.lha      mods/techn  36K+A little techno PT module by Breed
lns28_tomatEp1.lha   mods/techn 236K+Tomat Ep p1 - A happy tomato
lns28_tomatEp2.lha   mods/techn 134K+Tomat Ep p2 - meanwhile
lns29_arson.lha      mods/techn 230K+Premeditated arson - techno house
lns31technoEp1.lha   mods/techn 172K+Techno ep p1 - Monster
lns26_hardEp1.lha    mods/tranc 389K+Hardtrance ep p1 - snowblower
lns26_hardEp2.lha    mods/tranc 494K+Hardtrance ep p2 - On sale
lns27_goaEp1.lha     mods/tranc 585K+Goa Ep p1 - empty brain
lns27_goaEp2.lha     mods/tranc 450K+Goa Ep p2 - segregation of objekts
nearBreed.lha        mods/tranc 159K+A little trancy PT module by Breed
RachelRuns.jpg       pix/art    232K+Rachel Raccoon finishes running with a p
A2-G24bit_1.lha      pix/misc   2.2M+Astrosyn`2 - 24bit gfx compo entries [1/
A2-G24bit_2.lha      pix/misc   1.5M+Astrosyn`2 - 24bit gfx compo entries [2/
A2-GAscii.lha        pix/misc     7K+Astrosyn`2 - ascii graphics compo entrie
A2-GPixel_1.lha      pix/misc   1.3M+Astrosyn`2 - pixel compo entries [1/2]
A2-GPixel_2.lha      pix/misc   1.9M+Astrosyn`2 - pixel compo entries [2/2]
A2-GTrace_1.lha      pix/misc   1.1M+Astrosyn`2 - raytracing gfx compo entrie
A2-GTrace_2.lha      pix/misc   2.1M+Astrosyn`2 - raytracing gfx compo entrie
Notes1.5.lha         text/dtp   283K+ProPage4 Notes-print-Genie Deu&Eng
mpgerman.lha         util/misc    3K+German Catalog for Miamiphone V1.5
SummerGer.lha        util/time    3K+German Catalog for sguard V 1.0

Subject: 6/7/8 august 1999: chaos communication camp
Date:    Wed, 31 Mar 1999 22:02:56 +0200
From:    Chaos Update <chaos-update-owner@lists.ccc.de>
To:      "Chaos Update" <chaos-update@lists.ccc.de>

Liebe Hacker,

vor einiger Zeit hat die intergalaktische Kontaktgruppe des CCC ein
Notsignal empfangen: im Raumschiff Herz Aus Gold ereignete sich an Bord
ein schwerwiegender Computerfehler und bedarf nun einer dringenden
Reparatur. Die Kontaktgruppe verständigte sich mit der Bordcrew auf eine
Reparatur unter Gravitationsbedingungen auf unserem Planeten. Die
Vorbereitungen laufen auf Hochtouren und im August wird das Raumschiff
nun endlich landen.

     http://www.ccc.de/camp/story.html

Anläßlich der Ankunft der Herz Aus Gold organisiert der Chaos Computer
Club eine Drei-Tage-Hack-Session im Freien für Nerds, Hacker und Phreaks
aus der ganzen Welt. Die Veranstaltung steht in der Tradition der HEU
(93) und HIP (97) in Holland und damit für viel Spaß am Gerät. Gemeinsam
werden wir die Herz Aus Gold schon wieder flott machen.

     http://www.ccc.de/camp/camp.html

Das Camp findet vom 6. bis 8. August 1999 auf einer Wiese in der Nähe von
Berlin statt. Wir werden die notwendige Infrastruktur für einen
angemessenen Hackerurlaub bereitstellen (Strom, Internet und
Möglichkeiten zur Nahrungsaufnahme) und die Aktivitäten auf dem Gelände
koordinieren.

Du bist eingeladen, Dein Zelt und Deinen Computer mitzubringen und Deine
Geräte an das Campnet und damit an das Internet anzuschließen. Die
Internetverbindung wird befriedigend breitbandig ausfallen. Mehr Details
zur Technik später.

Alle Informationen (zur Zeit nur in englisch) finden sich unter

     http://www.ccc.de/camp

Die deutsche Web Site und eine umfangreiche FAQ sind in Vorbereitung.
Weitere Informationen werden über die camp-announce Mailingliste
erhältlich sein. Wer alle Informationen zum Camp automatisch erhalten
will, kann sich durch eine leere Mail an

     camp-announce-subscribe@lists.ccc.de

auf der Liste eintragen lassen.

Wir hoffen auf eine rege und aktive Beteiligung auf dem Camp (das Camp
wird für 1500-2000 Leute ausgelegt). Wir erwarten eine Vielzahl von
Projekten zu den unterschiedlichsten Themen (Kryptographie, Free
Software, Chipcards, Astronomie, Meteorologie). Wer Lust hat, eigene
Projekte auf dem Camp zu realisieren, sollte sich mit der Orga-Crew in
Verbindung setzen: crew@camp.ccc.de.

Für die Presse wird es besondere Richtlinien geben, die derzeit noch
ausgearbeitet werden. Auch dazu später mehr.

Chaos Computer Club
März 1999

bulllister.lha       comm/cnet    5K+Bull Lister Version 1.0
KewlStory_12.lha     comm/maxs   49K+Let your callers make up a story, 1.2
MagicFile_46.lha     comm/maxs  178K+Automated file menus & more for MAXs, 4.
EMR-ResTito.lha      demo/aga   3.9M+"Restito" by Embora - 6th at Astrosyn`2
PHT-Schedule.lha     demo/aga   3.1M+"Schedule One" by Phase Truce - 7th at A
DKG-BreezeNow.lha    demo/intro   5K+5th place at Astrosyn'99!
noe_ppc_c2p.lha      dev/asm    195K+Ppc c2p converters (8bpp and 15bpp)
gtshape.lha          dev/basic    3K+Blitz2 - code for fixing GTShapes
FlashROM_11.lha      disk/cdrom  16K+Amiga tool to change the flash ROM of Pl
b5guide.lha          docs/hyper 102K+Babylon 5 Episode Guide
ovenbird_src.lha     game/misc   41K+Source codes for Ovenbird v0.50
RushHour_16a.lha     game/misc  344K+Switch trafficlights, like C64 Traffic
MortalKombat2H.lha   game/patch   5K+MortalKombat2_Hd {4 disks)
PowerView.lha        gfx/show    75K+JPEG Viewer (CGFX and AGA) for PPC-Amiga
PowerView.readme     gfx/show     2K+JPEG Viewer for AGA and PPC (BETA!)
imdbDiff990319.lha   misc/imdb  1.5M+Diffs for the Internet MovieDatabase
mw_trust.lha         mods/wmr   1.4M+IMM: "Trust" by wOOd/Acid Demons
MMULib.lha           util/libs  218K+Library to ctrl the MC68K MMUs, beta
ShowMem.lha          util/moni   15K+Shows memory fragmentation via gfx
BenchTrash.lha       util/wb    185K+Global trashcan for WB, with eject suppo

sakkare.lha          biz/dopus  177K+Awesome theme for magellanII
sshnote.txt          comm/net     0K+Note regarding comm/net/SSH.lha.
GetAllHTML.lha       comm/tcp    13K+Auto-download entire web sites! (v0.61 )
MyHost.lha           comm/tcp     7K+Shows your host on one or all interfaces
FLP-Elthiag.lha      demo/aga   3.3M+"Elthiag" by Floppy - 3rd at Astrosyn`2
UDP_Chat.lha         dev/basic   94K+UDPfuncsV2.3 for Blitz-good for Net game
E-List9811.lha       dev/e      127K+All November 98 msgs on the AmigaE Maili
E-List9812.lha       dev/e       50K+All December 98 msgs on the AmigaE Maili
E-List9901.lha       dev/e       49K+All January 99 msgs on the AmigaE Mailin
E-List9902.lha       dev/e       53K+All February 99 msgs on the AmigaE Maili
AutodocV131.lha      dev/misc    28K+A really neat autodoc viewer v1.31 (OS3.
ReCatItProGRca.lha   dev/misc     5K+ReCatItPro v1.00 Greek catalog
MakeCDdeutschD.lha   disk/cdrom 322K+German documentation for MakeCD V3.2b
BUFF_Gde.lha         docs/hyper 100K+Buffy Vampire Slayer Episode Guide (51)
ACNews_9.lha         docs/mags   62K+E-zine focused on Amiga News: #9-Mar 99
SCSI_PCMCIA.lha      docs/misc  124K+Allows you to connect a SCSI PCMCIA read
startrekanm.lha      game/think 3.1M+Optional Anims My Star Trek Game
startrekprg.lha      game/think 998K+Updated Star Trek Game! Hires graphics!
Sezioni.lha          misc/misc  112K+Sezioni v2.0 DEMO (ITALIAN)
SpaTra06.lha         misc/misc   32K+Spanish Translations Pack 06 v0.10
Totogol.lha          misc/misc  132K+Totogol v3.6 DEMO (ITALIAN)
TotoSei.lha          misc/misc   61K+TotoSei v1.0 DEMO (ITALIAN)
lns22_peasants.lha   mods/techn 169K+British peasants - minimalism
lns23_cranium.lha    mods/techn 247K+My cranium is gone - minimalism
lns13_childe.lha     mods/tranc 281K+Children of the sun - softtrance
lns14_black.lha      mods/tranc 152K+The black death - softtrance
lns15_stack.lha      mods/tranc 296K+Smoke stack - hardtrance
lns16_desert.lha     mods/tranc 211K+Desert hero - hardtrance
lns17_light.lha      mods/tranc 346K+Let there be light - hardtrance
lns18_netto.lha      mods/tranc 405K+Nude in netto - hardtrance
lns19_pressure.lha   mods/tranc 235K+Endangered by pressure - acid+goa
lns20_secret.lha     mods/tranc 181K+Secret world - softtrance
lns21_Ra.lha         mods/tranc 188K+The eye of Ra - softtrance
lns24_coin.lha       mods/tranc 515K+Co-incidence - softtrance remix
lns25_tmt.lha        mods/tranc  31K+The morning trip - goa
bp_melt.lha          mods/wmr   553K+IMM: "Melt" by balistic/DiSC
ds-above.lha         mods/wmr   386K+IMM: "Above the Clouds" by Dawnstar
Sub.lha              pix/anim   844K+Sub anim with sonar sound in IFF-SoundAN
MODiskIcons12.lha    pix/icon   104K+Icons for 3.5" Magneto-Optical disks

From:    "Colin-Stewart Bridge Deady" <csbdeady@mythicz.u-net.com>
Date:    29 Mar 99 23:33:47 +0000
Subject: Summary 13
To:      kosh-general@kosh.net

This is a MIME encoded multipart message. The fact that you are reading
this means you don't have a MIME capable mail program. You might still
be able to read part of the mail's content, but some of it may require
a MIME capable mail reader to decode. Following are some URLs where
you can find MIME-capable mail programs for common platforms:

  Amiga............: MicroDot-II  http://www.vapor.com/
  Unix.............: Metamail     ftp://ftp.bellcore.com/nsb/
  Windows/Macintosh: Eudora       http://www.qualcomm.com/

General info about MIME can be found at:

  http://www.cis.ohio-state.edu/hypertext/faq/usenet/mail/mime-faq/top.html

--=_=8<==MD237000DDB-2E5C69D0==8<=_=
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi all

Summary 13 enclosed. Many thanks to Robert Wise and John Chandler who
helped out with writing it.

It's a long one - a very long one - and I decided to keep John's
excellent contribution in a separate file to reduce the size of the
main file - although admittedly this is a larger_than_average summary.

If we get this many contributions to the general mailing list in the
future I will need help summarising the ML on a regular basis -
alternatively -please- take a lot of topics to the appropriate other
lists as I can't summarise them for lack of time.

Regards
-Bridge


--
http://www.mythicz.u-net.com | csbdeady@mythicz.u-net.com
ICQ:29145054 | DT-MUD:sunsite.auc.dk:4242
Amigan | Vegan | KOSHan Go for a swim in the object sea,
http://www.kosh.net | Storm of the Eye GUI-PBEM http://www.2bp.com/

--=_=8<==MD237000DDB-2E5C69D0==8<=_=
Content-Type: text/plain; charset=us-ascii; name="ksum13.txt"
Content-Transfer-Encoding: plain (7/8 bit)
Content-Disposition: attachment; filename="ksum13.txt"
X-MD2-FilePath: Work:mythicz/ksum13.txt

KOSH [Kommunity Orientated Software Hardware]

Weekly Summary

Week Commencing: 20th March 1999

Number: 013

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.

The Summary this week was completed jointly by myself, Bridge Deady, Robert
Wise and John Chandler. I have incorporated Robert's sections into the main
summary but I have enclosed John's separately to allow for different
pagination.

a)

Subject: Keyboard mapping

Summary of debate: An idea posted is that it would be useful if you could swap
                   keys of the keyboard in software. For example, if you wanted
                   to replace "x" with "y" you would just run the appropriate
                   mini application, specify the keys to swap and choose OK.
                   This would allow people who would like keys to be mapped
                   slightly differently to be able to accomplish this.

                   It was further suggested that this could later be
                   implemented in hardware by allowing physical hotswapping of
                   keys on a keyboard. Does USB have the bandwidth and features
                   to enable this?

                   Each key could have the character it represents embedded in
                   it, interfacing through a quick-connect/disconnect plug. An
                   advantage of this is that if a key stopped working you could
                   just buy a new key rather than a new keyboard. If you needed
                   more space for a larger alphabet you could just clip on a
                   new section to the board and populate it with your chosen
                   keys. Perhaps this interfacing could be achieved with PIC
                   chips cut down to size?

                   It was pointed out that this is all part of a larger picture
                   about the ability to input into a computer in a native
                   language. To this end it would be nice to get involvement
                   from people in Asia in KOSH. The system should support many
                   languages as standard (presumably via language objects).

                   Keyboards could be handled via a keyboard driver object. The
                   actual keyboard can be anything the user wants to use. A
                   stream of input messages come from the keyboard which could
                   be unicode characters or special events (eg: Help key)/ If
                   its a smart keyboard (like USB) it will automatically start
                   the correct driver.

                   Suggested that a lot of what has been said could be
                   accomplished by a configurable touch screen although it
                   would lack tactile feedback. Tactile feedback could possibly
                   be handled via a gell that becomes progressively harder as
                   an electric field is applied to it - at the points where it
                   is pressed.


                   Different keyboard input objects based on Unicode could
                   handle any input required. Alternatively have an intermediate
                   object between the keyboard input object and the input
                   handler object, which may translate.

                   The Dworak keyboard that maps the most used keys closest to
                   where one has ones fingers was mentioned.

                   Could each key have a LED like the one on the Amiga Caps
                   Lock key?




b)

Subject: Cooling KOSH (was Waterproofing KOSH)

Summary of debate: Perhaps by using conductive fluid pipes in the computer one
                   could cool it.

                   Another idea would be to have slots on top of the machine
                   (not the side where they currently are), but this would take
                   us back to the first problem - coffee spills and dust.
                   Therefore the slits could be at the top edges of the case
                   facing out of either side with a slight V-shape in the
                   inside top of the case directing hot air that rises to these
                   outlets. Any foreign bodies entering these outlets could be
                   made to fall down channels in the inner side of the machine
                   and hopefully not enter the fragile innards.


c)

Subject: Chunky pixel and bit plane graphics modes

Summary of debate: When we get around to designing KOSH graphics cards can we
                   try to use the advantages of both systems mentioned above?

                   By connecting the vsync signal from the graphics card to a
                   hardware interrupt pin on the CPU we can make real-time
                   window dragging look smooth and fluid.

                   KOSH should use the inbuilt interrupt feature of many
                   graphics cards to accomplish this.

                   KOSH graphics cards could contain some form of copper, maybe
                   a more advanced version that allows 2D operation (which
                   would speed up the GUI).

                   Further questions raised: do we want a graphics card at all
                   when instead we could use a modular design, keeping the RAM,
                   DAC and custom chips as separate, scalable and optional
                   modules?

                   Do we want shared memory for graphics, data and sound like
                   the Amiga's chip RAM?



d)

Subject: Memory protection

Summary of debate: Would it be possible with today's memory management units to
                   protect private members of a single object?

                   Dave Haynie has previously suggested a system using flexible
                   context objects, which can live in at least four different
                   protection levels (app, global, object, and system).

                   Only if you wanted to devote a large chunk of memory to each
                   such object. An MMU, for good reason, works in page-sized
                   increments.

                   Could there be a standard way to lock an object in memory
                   for reading and writing to prevent another task or person
                   from changing the object that is curently being used?

                   Only if you wanted to devote a large chunk of memory to each
                   such object. An MMU works in page-sized increments.

                   However from the Amiga we can see that a system can be
                   stable without protection - it also shows where protection
                   is needed.

                   Only write-protection is needed to avoid having
                   applications trash each other's memory. However security
                   reasons would mean that you may not want someone to scan all
                   your documents and therefore read-protection is also needed.

                   What mechanism might exist to identify methods that a given
                   object understands? How would it be possible to tell that a
                   particular subclass of text object manipulator understands
                   font styles or not, or some similar thing? Not necessarily
                   determining whether it responds to a specific method, but
                   whether it has an equivalent method.

                   To physically protect objects from being altered by
                   malfunctioning classes each object could have its own memory
                   space. Knowing when to protect the object is as important as
                   actually protecting it.


e)

Subject: Book recommendations

Summary of debate: Booch's book about Object Oriented Analysis and Design,
                   (Grady Booch. 0-8053-5340-2) comes recommended.
                   Also recommended is Software Inspection by Gilb and
                   Graham (0-201-19246-2, 0-201-63181-4), which gives good
                   ideas about how to increase the quality of software.

                   Scribe's note: Books are summarised on the kosh booklist
                   website - see a previous summary for the URL.



f)

Subject: KOSH training

Summary of debate: Many people involved with KOSH may not that well versed in
                   the technology behind the proposals. Mario Saitti is willing
                   to help set up a system for KOSH to teach structured
                   programming methodology/Data Structures/SSADM/computational
                   to anyone interested.

                   Suggested that we should be thinking about teaching OO, not
                   structured programming. Structure programming doesn't really
                   go well with the object sea.

                   OO Design could also be a very valuable skill for all KOSH
                   members.

                   Could such training "courses" actually be devised?
                   Supplementing such training with books was recommended.


g)

Subject: Against hosted

Summary of debate: One scribe-e pointed out that they are against running hosted
                   versions of KOSH. Their reasoning is that there may be little
                   point in redefining computing to use modern methodology if we
                   put it atop of a base that is at least 20 years old. While
                   ensuring market compatibility is the compromise worth it?


h)

Subject: Why there should be an Object Sea

Summary of debate: One scribe-e pointed out they currently view the object sea
                   as just a set of descriptors and protocols made up of sub
                   classes which determine how the system will handle the
                   object.

                   The advantages of this approach include the fact that it
                   promotes really serious, heavy use of code reuse and
                   polymorphism. Together, these can lead to both better
                   performance and far more reliable code. It is then easy to
                   add behaviours to the system.

                   why is there a need for a frozen form?

                   A datatype still needs to open the JPEG file, close it later,
                   perhaps committing or forgetting edits at the same point.


i)

Subject: COMAL, REBOL, JIT & Basic KOSH

Summary of debate: Should KOSH come with a BASIC-like interpreted language?

                   A COMAL interpreter included with KOSH as standard was also
                   suggested. COMAL is very widely supported.

                   How about REBOL which is a messaging based interpretive
                   language currently going towards version 2.0 and developed
                   by Carl Sassenrath? See: http://www.rebol.com <=Some like
                   REBOL, others are less impressed.

                   Why bother with an interpreted language when with KOSH we
                   are thinking of the possibility of programs compiling at
                   either install or run time from a slim binary type of
                   format? How about a JIT compiled language as we would not
                   lose significantly in time that way?

                   Suggested is making a computer language that is more like
                   the equations that scientists and people in general have
                   been using all their life. Pointed out that we may not want
                   to create a new language. Mentioned that instead of a
                   compiled language one that halts and hilighted errors would
                   be good.

                   The standard compiler shipped with KOSH could be simple with
                   a more advanced highly optimised version available for
                   purchase.

                   In regard to OO rather than structured programming, see
                   Farenheit at http://www.sgi.com for some of the newest
                   declarative systems.


j)

Subject: CORBA links

Summary of debate: See:
                   http://www.corba.org ? Try searching for papers and AOOC.
                   http://www.cetus-links.org/ have some links that might be of
                   interest.

                   Also see: http://www.omg.org (or something similar) - the
                   parent organization is something like "Open Management
                   Group".




k)

Subject: Structured design methodology

Summary of debate: Suggested that we could all write a few lines on structured
                   design methodology and someone could summarize it for the
                   glossary.


l)

Subject: Accessing KOSH (continued)

Summary of debate: A completely aural interface for the system could be very
                   useful for those who are completely blind.

                   However this could have disadvantages such as if the
                   interface was left turned on next to a radio. Perhaps
                   preface commands to the computer with another word (aka Star
                   Trek).

                   Any audio control should be able to understand conceptual
                   terms - most likely via some AI.

                   A true 2-colour screen could be useful for someone who is
                   colourblind.

                   Avoiding colour clash (a form of colour blindness) when
                   certain colours are placed on other colours should be
                   paramount in KOSH.

                   Braille keyboards and a Braille screen were further
                   suggested.

                   Circular radar like pulses going to a mouse pointer when you
                   press a shortcut key could be used to help keep track of the
                   pointer.

                   The Amiga and Mac ability to flash the screen when there is
                   an error as well as provide a beep should be included.

                   We should also look at alternatives to keyboard + mouse
                   including joystick control amongst many possibilities.

                   Mario Saitti has suggested that issues like these would need
                   an entire working group of their own.



m)

Subject: DLL's

Summary of debate: Was mentioned by a number of people that we should stay away
                   from a system similar to Windows DLL files as these can
                   create severe problems when things go wrong.


n)

Subject: Garbage collection

Summary of debate: Garbage collection from LISP could be used. Object Seas
                   based on their existence are suggested as the way to go.


o)

Subject: Localised languages

Summary of debate: Locale on AmigaOS allowed easy adaptation to many languages.
                   By incorporating this in some form into KOSH the system as a
                   whole becomes even more inclusive.

                   To fully internationalise KOSH it was suggested that a
                   mixture of languages should be useable at once. An example
                   given was Swedish in a wordprocessor but something else in
                   the other applications.

                   KOSH from the ground up should be designed to be flexible
                   and powerful in respect to language implementation including
                   Kanji which appears to be very complex.


p)

Subject: Punch cards

Summary of debate: KOSH should support punch cards as there is a lot of data
                   stored on them which is currently difficult to access.

                   It was pointed out that this could be achieved by placing
                   the punch card in a scanner and then interpreting the
                   resulting picture.


q)

Subject: KOSH-OO-help ML

Summary of debate: A mailing list with the above title was suggested by John
                   Gustafsson so him, Dave and others can post a mail now and
                   then about something about OO and those interested could
                   talk about it.


r)

Subject: Get together

Summary of debate: Suggested we should all get together to celebrate the
                   release of KOSH 1.0 when it is out. Joel Newkirk wants to
                   know if we want to go to a party at his place? Such an
                   opportunity will give us all a chance to meet each other.
                   Dave Haynie then goes and invites us all to his place for a
                   Summer party in the year 2000 - what a nice gesture!. Mario
                   Saitti then makes further offers around the theme of a get
                   together.

                   Oh and ideas for the place to celebrate KOSH 2.0 are coming
                   in now as well:P


s)

Subject: Hardware Procurement WG

Summary of debate: Joel Newkirk suggests the above working group to establish
                   means of procuring hardware for testing, kommunity needs,
                   individual purposes, etc at the lowest available prices.
                   Maybe establish a specific physical/legal base in the state
                   of Delaware, which is conveniently free of sales tax, yet in
                   a convenient location at the heart of the US East Coast
                   Metro-Belt.


t)

Subject: Users as objects

Summary of debate: Suggested that we could tread users as objects or a set of
                   objects, with permissions for various things and levels
                   being objects or object-related as well.

u)

Subject: Multiuser systems

Summary of debate: Mentioned that would we need a multiuser system? With KOSH
                   being designed so that it is fast, easy and fun to use
                   rather than a mainframe OS with terminals and users perhaps
                   multiuser is unnecessary.

                   However multiuser systems may be a must for any connected
                   computer. File sharing would be hard and inefficient without
                   a multiuser system.

                   The multiuser model could be defined and then set the single
                   user model as the degenerate case.

                   By being able to boot the system into a configuration mode
                   that is free of user context software and hardware could be
                   easily added globally.

                   Data, applications and hardware could all be user-specific
                   (with the ability to add other users) or global in their
                   availability. Therefore we could have just one KOSH
                   distribution with many different levels of users. Sharing
                   like this could also be done over a network.

                   If every KOSH machine is fully multi-user it would mean that
                   identifying oneself to any machine would allow access to all
                   of that users resources and settings. Suggested that KOSH
                   should see multiuser as adding "personal" resources and
                   access privileges to the generic system.


v)

Subject: Resolving handles

Summary of debate:  Resolving handles and finding methods/interfaces is likely
                    to take at least some processor time. Suggested these
                    things could be cached.

                    Further suggested is that we could have some objects built
                    at install time and updated at runtime if applicable, to
                    handle the resolving, on the machine the application or
                    object's installed on. The OS then wouldn't have to do a
                    new complete resolve each time the object were to be
                    invoked.


w)

Subject: KOSH Vocabulary WG

Summary of debate: Ruward F. Leenstra has suggested that it is time to create
                   the above named working group. As this will help with
                   reading Dave's paper on the Object Sea by defining and
                   explaining the terms contained within it.

                   A lot of interest was shown in this idea.


x)

Subject: KOSH FAQ

Summary of debate: Suggested that for subjects covered by KOSH mailing lists we
                   could have a frequently asked questions section of the web
                   site.


y)

Subject: Object synchronization

Summary of debate: One of the concepts arising in the discussions is the ability
                   to synchronize object by transferring the events (methods)
                   from one system to another. If the objects in question are
                   identical then no problem exists. If they are different, but
                   significantly similar then the same effect could be achieved,
                   in a limited fashion. The question is how can we determine
                   what methods a given object will respond to, and if those
                   methods are globally standard or intrinsic to that object?

                   By looking at the objects class hierarchy, the class
                   definition will determine the methods an object will
                   understand.

                   Suggested that we let the object manager be responsible for
                   almost everything related to this.  Instead of calling an
                   object directly or using an object that pre-exists, we could
                   call the object manager to rebuild an appropriate object. All
                   calls to the object manager should be abstract under this.

                   Object Synchrony developed as an approach where two compatible
                   objects on different systems are synchronized by duplicating
                   the events therein or methods sent thereto between 2+ objects.

z)

Subject: Alternatives to the monitor

Summary of debate: Audio cues discussed in depth. They have advantages over
                   simply enlarging the text on screen, although having the
                   ability to work split at the OS level (not just in
                   applications) with one half at 100% magnification and the
                   other at anything you choose would be neat.

                   See http://www.cast.org - Center for Applied Special
                   Technology. Part of their purpose is to expand the
                   accessibility of computers. Their Blobby tool at
                   http://www.cast.org/blobby is very useful to check web pages
                   for accessibility.

                   Suggested KOSH could contact relevant organisations (eg:
                   Royal Society for the Blind in the UK) and tell them that we
                   are interested in getting opinions of our ideas from
                   experts in the field, and that we are eager to try to
                   incorporate capabilities they can show to be helpful.

                   It was stated by someone who is visually impaired that a
                   windowing system is useless for the blind and if you are
                   otherwise visually impaired such a system is poor.


1a)

Subject: Window shapes

Summary of debate: At the moment almost all windows are rectangular. If KOSH
                   implemented a form of masks from the outset the windows
                   could be any shape desired.


1b)

Subject: VB Problems

Summary of debate: See the following re Visual Basic and problems with it:
http://www.vb-zone.com/upload/free/features/vbpj/1999/mckinney/mckinney1.asp#1


1c)

Subject: Mouse movement

Summary of debate: The mouse pointer in KOSH must not be jerky, it must be
                   completely fluent.


1d)

Subject: More mouse control

Summary of debate: A small trackball under the finger on top of a mouse could
                   be used in addition to the mouse itself for panning and
                   zooming etc.

                   How about a horizontal wheel as well as the vertical one.

                   Mice that sense rotation were suggested.

                   Pointed out that if the drivers were written better the
                   support for the mouse could be automatic without an
                   application exactly having to support it.

                   A trackball or a trackpad in the center of a split keyboard
                   was suggested as an alternative.


1e)

Subject: Cartesian Coordinates

Summary of debate: Cartesian Coordinates were suggested to be used with the
                   Object Sea as 2D and 3D objects. However they can be
                   difficult to deal with a lot of non-rectilinear objects and
                   waveforms.


1f)

Subject: Alternative caching method

Summary of debate: Could we create a new 'protected' directory object that is
                   accessible only to the parent task and appears and
                   disapears along with it? This could be useable to get
                   around a new EU ruling that caching is against copyright
                   law.


1g)

Subject: Mutual NDA

Summary of debate: To protect KOSH work and the work of individuals involved it
                   may be necessary at some stage in the future to use mutual
                   non disclosure acts in some areas of the Kommunity - namely
                   in certain Working Groups set up for certain reasons. Anyone
                   could have access to this but they would have to sign a
                   mutual NDA with KOSH, Inc. to gain access.


1h)

Subject: High Performance Computing Users (HPCU) Group Annual Conference

Summary of debate: See: http://www.hpcu.org re the above, or the email posted
                   by Giorgio Gomelsky (gio1@interport.net) on the 26th March
                   entitled "Fwd: Computers/computation/standards" which is a
                   forwarded message calling for computer papers on an array of
                   topics.


1i)

Subject:  Using a new object model rather than an existing one.

Summary of Debate:  Several features were proposed for the KOSH object
                    model which do not exist in current object models
                    (specifically C++'s.)  One of these features is
                    method transparency/translucence.  Using this
                    feature it is possible to create a transparent/
                    translucent container class which receives methods
                    and passes those methods along to the objects the
                    class contains.  Method transparency/translucence
                    can be utilized by an object to "broadcast" a
                    method to many recieving objects.  There was some
                    concern that this would be wasteful, in that during
                    a broadcast many objects could receive methods they
                    do not implement, and be forced to ignore those
                    methods.  Used appropriately, however, the ability
                    to "broadcast" methods would be a powerful tool.
                    An example of a translucent container would be a
                    generic-disc-object-container.  This would be a
                    container class that held all the information
                    necessary to store an object that exists in memory
                    on the disc.  The advantage of this is that while
                    the object is in memory it is not burdened with the
                    information about how it is stored on disc, and the
                    information about how to store an object on disc
                    can be implemented once, rather than over and over
                    again for each class.

                    Another feature proposed for the KOSH object model
                    was bidirectional polymorphism.  Here methods can
                    be sent to a class which does not implement those
                    methods but may implement them at some point in the
                    future.


1j)

Subject:  "Model-View-Controller" GUI Implementations

Summary of Debate:  Under this common method for GUI implementation
                    each GUI component is broken into three pieces.
                    The Model consists of the logical representation of
                    the component, the View consists of the visible
                    representation of the component, and the Controller
                    consists of mechanisms to which the component
                    responds.  This model originated in Smalltalk and
                    is used in QNX and in modified form in Java
                    JFC (SWING)


1k)

Subject:  Polymorphism

Summary of Debate:  Polymorphism was described as a subclass being
                    functionally the same class as it's parent class.
                    It was noted that this would be useful when
                    attempting to synchronize heterogenous objects.  As
                    long as the objects shared a common ancestry they
                    would have a set of common methods.  C++ uses
                    "pure virtual methods" in it's handling of
                    polymorphism, which are methods that are left
                    unimplemented in a parent class and must be
                    implemented in all subclasses of the parent.


1l)

Subject:  Object Links

Summary of Debate:  Anyone wanting to read more about object
                    orientation should check out the following:
                    Very Introductory Stuff
                    http://www.soft-design.com/softinfo/objects.html
                    Smalltalk ("Squeak" is a popular free subset
                    implementation)
                    http://www2.ncsu.edu/eos/info/ece480_info/project/
                        spring96/proj63/www/index.html
                    http://squeak.cs.uiuc.edu/
                    http://www.ddj.com/articles/1999/9901/9901k/
                        9901k.htm (funny)
                    http://www.stic.org/

                    Eiffel
                    http://www.eiffel.com/doc/manuals/language/intro/
                        page.html

                    Java
                    http://128.95.4.112/homes/gjb/doc/java-lang/
                        index.htm
                    http://www.javasoft.com/docs/books/tutorial/
                    http://www.javasoft.com/beans/docs/spec.html


--=_=8<==MD237000DDB-2E5C69D0==8<=_=
Content-Type: text/plain; charset=us-ascii; name="Ksum13a.txt"
Content-Transfer-Encoding: plain (7/8 bit)
Content-Disposition: attachment; filename="Ksum13a.txt"
X-MD2-FilePath: Work:mythicz/Ksum13a.txt

Object Technology & Resources Summary

** Efficiency, Flexibility & Classes

The discussion mentioned the trade-offs required to balance efficiency and flexibility. Concerns about
making unnecessary calls to objects which may not implement a specified method was countered with the
fact that broadcasting requests can often be more efficient than implementing suitability tests.

It was also pointed out that it is better to build an object in runtime from appropriate classes using
predefined methods. An 'upgrade flag' would be present in the system: objects could be 'frozen' to assist
with performance, but re-built by the object manager during each upgrade. Classes unable to fulfil a
functional requirement are ignored - this leaves a missing function, but is highly unlikely to cause
anything to fail.

Properties of objects shouldn't be restricted in general - UI characteristics, for example, could
legitimately be inherited by 'non-UI' objects in order to, say, provide display and user-interaction
parameters. Developing hybrid weirdity (great term!) is another reason for being able to want methods
mutating, but without the object code changing. A functional flow interface with user interaction provides
an example of this: streaming data and live interaction with adaption being performed - methods adapting
to the quality and quantity of data to change the visualisation. Dynamic artwork is also mentioned, as is
being able to change colour representation or whatever. To quote Paula Lieberman:

	"let's add some purple dye up there at time N, and at time N+1 change the dye to yellow, and
	when I press the Escape key, make it violent chartreuse with an A minor chord on a organ sample
	at fff....."

In essence, you need to be able to ensure the flexibility is there to cope with the things we didn't
originally anticipate. [John's note: truly creative stuff comes from really bending things totally out of
shape - if you can't do that, creativity is limited]. The needs of users can often be different from the needs
of programmers, which suggests we must make it easy for developers to create the software the users
want, and not their own 'toy pet'.

** Selfmodifying Code

Comments on selfmodifying code spawned some interesting points. Experience of LISP has given a sour
opinion of selfmodifying code to many, and it is indeed a bad idea in most cases (selfmodifying code, that
is - not LISP!). Modern computers, with varying cache capabilities, can easily have performance
degraded by selfmodifying code. Well, if you do it wrongly it can - but if you do it right it can improve
things quite considerably. [John's note: compare to the issue of 'goto' - while a bad thing for almost all
situations, it does have its uses when handled properly].

The cache problem can be handled sufficiently by flushing the first level cache. However, as cache sizes
get bigger and more processors are added you have more caches to flush. The Intel Merced, for example,
will probably have an 8 MB cache, and be present in multiple-CPU configurations.

Furthermore, it's important not to get confused about what selfmodifying code is:  it's code directly
changed during execution. However, if this code is actually rewritten to cover different cases as multiple
sections of code accessed through conditional branching you can develop alternatives for most uses of
selfmodification without cache problems and the like which can degrade performance. Of course, you
could create versions of functions/methods for a given system and just swap a pointer to direct code to the
right method - selfmodification would then only occur at the moment code is first loaded up. It was
mentioned that selfmodification should even be physically forbidden through techniques such as write-
protection of memory.

Are some of us trying to out-optimise modern optimising compilers by any means necessary? Apart from
keeping code compact (not really much of a necessity these days and still achievable through other means)
selfmodification can be replaced by more considered, structured programming approaches.

** Structured Programming

Ah, structured programming... In particular, criticism about universities and other institutions
(particularly in the west) not placing enough emphasis on structured design and programming techniques.
[John's note: Oxford Brookes University, UK taught me structured programming and design with great
emphasis, so not all universities are bad].

Good languages mentioned for teaching structured programming included Pascal and Modula-2 (praise to
Wirth!) as well as Java, while C and C++ came under fire for being unnecessarily complex,
unstructured and unfriendly. C++ has also helped destroy some companies, apparently! [John's note:
Sounds like C++ and ISO 9000 are related...]


--=_=8<==MD236FCC7A3-1EFDE8CC==8<=_=--

--=_=8<==MD237000DDB-2E5C69D0==8<=_=--
(end of MIME multipart message)