Path: utzoo!utgpu!water!watmath!clyde!att!rutgers!ucsd!nosc!helios.ee.lbl.gov!lll-tis!ames!amdcad!sun!pitstop!sundc!seismo!uunet!mcvax!ukc!eagle!rjf From: rjf@eagle.ukc.ac.uk (R.J.Faichney) Newsgroups: comp.windows.misc Subject: Re: Cut-and-paste (was Re: sharedx and remote conferencing) Message-ID: <5461@eagle.ukc.ac.uk> Date: 18 Aug 88 10:50:06 GMT References: <5411@eagle.ukc.ac.uk: <5442@eagle.ukc.ac.uk> <3154@geac.UUCP> Reply-To: rjf@re.UUCP (R.J.Faichney) Organization: Computing Lab, University of Kent at Canterbury, UK. Lines: 109 In article <3154@geac.UUCP> david@geac.UUCP (David Haynes) writes: >In article <5442@eagle.ukc.ac.uk: rjf@ford.UUCP (R.J.Faichney) writes: >: >:If we try to strictly separate user-interface from the (rest of the) >:application functionality we come across certain problems in deciding >:just what goes where. One of the most difficult is cut-and-paste. My >:view is that this is part of the functionality, not the interface. > >This is very confusing since you use the terms "interface" and "functionality" >without defining what you mean by those terms. Going by what follows, you seem to have worked it out. >:if you merely copy something from one application, that application >:need not know, nor do anything about it - but the one at the other end >:certainly should. > >In what sense? Yes, it should be in a state to accept input into a >given area, but how is this different from accepting input from a >keyboard? There may be no great difference as far as the functionality is concerned, but there is certainly a difference for the interface. >Yes, the addition of cut and paste capabilites requires more functionality >to be added to the application - I doubt that anyone disagrees with that, >but to the level of proposing a separate communications path? For the >most part, this is absurd! If you stop to consider all the applications >for which you might want to communicate and the resulting complexity of >setting up distinct (efficient) communication between them all, it should >become quickly apparent why this approach is unwise unless there is another >factor (bandwidth, data complexity, etc) to justify the special relationship >between the applications. Just what degree of complexity are we discussing? How efficient does this have to be, given modern machine capacities? 'Special relationship'? You seem to be trying to make this seem more difficult than it is. You say it is apparently unwise, but I've done it. Admittedly it has not yet been tested under a very heavy load, but it seems OK so far. And it does lots of other things besides cut-and-paste: connections and discrete messaging, transparent networking, find details of other applications, 'wild cards' in addressing, etc. (Incidentally, networking for inter-functionality comms is particularly difficult to do via a system where the server is tied to a display which is quite irrelevant. I know -- I've tried it.) >[About increasing 'connectivity' for increasing numbers of applications] > >The point is: For a generalized cut and paste facility, the only >intelligent way to achieve this is via a byte streams from the >user interface. Any other mechanism soon grows to be unwieldly. >Remember, as each new component is added, the complexity of each >program increases (an ugly thought). There is very simple answer to this: instead of a fully interconnected net of applications, have a communications server, with just one connection to each application -- like a telephone exchange. Which is how I've done it. Both discrete messaging and direct connections are easily simulated using server-mediated connections. In article <532@ashton.UUCP> dwiggins@atsun.UUCP (Don Dwiggins) writes: > >Protocols for doing that sort of thing are beginning to appear, e.g. Sun's XDR, >Microsoft's (or is it IBM's?) DDE, etc. It's Microsoft's. Though protocols are at least as important as what I've been doing, possibly more so, and highly relevant, we're actually talking apples and oranges here. I don't know much about DDE, but XDR is all about communicating structured data. I've been concentrating on a mechanism for communicating unstructured data which could have more sophisticated facilities built on top, but which made addressing in particular easy for the application programmer, and had the other facilities mentioned above. Aside from data structure, dp is higher level and of much wider functionality than XDR, and more flexible, more portable and of wider functionality than DDE (I believe). And the structured data facilities can be easily added. Though I should add that dp is aimed more towards applications which have been cooperatively designed (or, I would say, cooperatively had minor modifications made) than either DDE or XDR. You pays your money.. >The basic idea is machine-independent >representation and transmission of complex data, controlled by a cooperating >producer and consumer. Nothing in this requires or precludes UI involvement. Agreed. It is at a lower level than the interface/functionality distinction. >Given that such a facility exists, however, it's useful for the UI at some >level (window system, UIMS, or what have you) to know about it, so that it >can use it to support the Cut-and-paste metaphor and perhaps offer other >visual ways to coordinate data transfer across applications. If the UI/window system wants to use it 'internally', why not? But it shouldn't encroach on what is, in principle, application functionality stuff. See above and elsewhere ad nauseum. Also remember the ;-) in the original posting. I'm not seriously suggesting that cut buffers should be removed from X -- just that to use them is to compromise (however slightly) a generally accepted principle of software engineering: that of maximal separation of user-interface from application functionality. Some I/O is user I/O, some is like user I/O, some is nothing like user I/O. I have something which handles the latter two equally easily, therefore, with the window system, covering all inter-program comms requirements. If you insist the the former two belong together, I won't argue anymore -- it's just a little less work for my system to do. Robin Faichney