Return-Path: Received: from icon2.iconimaging.net (icon2.iconimaging.net [209.152.93.214]) by clubserv.rp-online.de (8.9.1a/8.9.1) with ESMTP id AAA02592 for ; Tue, 30 Mar 1999 00:38:31 +0200 (METDST) Received: (from daemon@localhost) by icon2.iconimaging.net (8.8.6/8.8.6) id QAA30253 for kosh-general-outgoing; Mon, 29 Mar 1999 16:24:12 -0600 Received: from serv1.is1.u-net.net (serv1.is1.u-net.net [195.102.240.129]) by icon2.iconimaging.net (8.8.6/8.8.6) with ESMTP id QAA30244; Mon, 29 Mar 1999 16:24:07 -0600 Received: from [195.102.200.235] (helo=p107.nas2.is5.u-net.net) by serv1.is1.u-net.net with smtp (Exim 2.00 #2) id 10RkXA-0005rD-00; Mon, 29 Mar 1999 22:29:28 +0000 From: "Colin-Stewart Bridge Deady" Organization: Mythicz Date: 29 Mar 99 23:33:47 +0000 Subject: Summary 13 Message-Id: To: kosh-general@kosh.net Cc: ben@kosh.net Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=_=8<==MD237000DDB-2E5C69D0==8<=_=" X-Mailer: MicroDot-II/AmigaOS NC 1.0a Sender: owner-kosh-general@icon2.kosh.net Precedence: bulk Reply-To: kosh-general@kosh.net X-UIDL: 0dc41eb8b78e81cbf6a1ceae74ab52c5 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)