rjf@eagle.UUCP (06/01/87)
@eagle.ukc.ac.uk> rjf@ukc.ac.uk (R.J.Faichney) writes: >In article <6787@mimsy.UUCP> steve@mimsy.UUCP (Steve D. Miller) writes: >>[..] >>If anyone does an implementation for SunView, NeWS, or X, I'd love to >>take a look... >> >> -Steve > >I'm working on something like this (actually, The Interconnection of Highly >Interactive Software Modules) right now, supported by the UK Science and >Engineering Research Council. An actual product is not the aim of this >research - we are in the early stages yet - but there may be a by-product. >Please email me if you are interested. > I've since come to the conclusion that, in the cir- cumstances, not to utilise the massive net.brainpower out there would be a criminal waste of resources. So, below you'll find a little more detail on what I'm doing, and I hope that it will stimulate further discussion, even if only to tell me that I'm barking up a gum tree. The general idea is to design and implement a pipe analogue for graphics-interfaced (WIMPS) programmes. Now, the reason why you can't simply send the output of one WIMPS prog to the input of another, is that instead of being a character stream, as in the good old days, it's all sorts of rasterops and similar assorted nasties. But, if the prog is structured properly (you never know) then all this graphics stuff is confined to the user interface. (For simplicity, say we confine it to text manipulating progs for the moment.) The application functionality, and therefore the application (using the word here as opposed to user interface) func- tions, should be exactly as in the old glass-teletype ver- sion. So why not grab information between application func- tions and user interface, and send it off to the other progs app func, bypassing both UIs? What I'm actually proposing here, is that, given some sort of interconnection standard, and perhaps an interconnection toolkit analogous to a UI toolkit, a third layer is inter- posed between UI and app func, which will allow any two or more progs appropriately designed and implemented, to exchange data and/or commands to their hearts content. (Thanks to Gilbert Cockton for the three component model, though his was intended to solve different problems.) The app func won't know whether anything it gets is coming from 'its own' UI, or another prog altogether (or maybe a command file), and the UI won't know whether what it's handling is going to 'its own' app func and/or another prog and/or being written to a command file. It's difficult to envisage any sort of widely accepted interconnection standard in the foreseeable future, but at least producers of software tools (like our Software Tools Group here at UKC) might find this a practical way of ensur- ing that their own products can communicate, should they wish to do so - and it's a fairly safe bet that many more than at present would wish to do so, if they thought it was practical. So - what I want to know is, are my colleagues merely being nice to me, or is this a good idea? Any and all comments - especially on what facilities you'd like to see in an inter- connection toolkit (I already have an interconnection server: a sort of computer program dating bureau) and how these might be implemented - gratefully received. Post or email as you think fit. Robin Faichney rjf@uk.ac.ukc ...mcvax!ukc!rjf
carlson@lll-tis.UUCP (06/02/87)
In article <3054@eagle.ukc.ac.uk> rjf@ukc.ac.uk (R.J.Faichney) writes: >In article <3042@eagle.ukc.ac.uk> rjf@ukc.ac.uk (R.J.Faichney) writes: >>In article <6787@mimsy.UUCP> steve@mimsy.UUCP (Steve D. Miller) writes: Perhaps we need a group, comp.ui for user interfaces. Or will the windows groups handle it? John Carlson Internet: carlson@lll-tis.arpa UUCP: lll-lcc!lll-tis!carlson