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