Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!ames!elroy!mahendo!wlbr!scgvaxd!ashtate!dwiggins From: dwiggins@ashtate (Don Dwiggins) Newsgroups: comp.windows.misc Subject: Re: Cut-and-paste (was Re: sharedx and remote conferencing) Message-ID: <532@ashton.UUCP> Date: 13 Aug 88 23:01:54 GMT References: <5411@eagle.ukc.ac.uk> <5442@eagle.ukc.ac.uk> <567@motsj1.UUCP> <5450@eagle.ukc.ac.uk> Reply-To: dwiggins@atsun.UUCP (Don Dwiggins) Organization: Ashton-Tate, Torrance, CA Lines: 21 In article <5450@eagle.ukc.ac.uk> rjf@ford.UUCP (R.J.Faichney) writes: >PS Maybe I should make what I'm suggesting a little clearer: the major >distinction between the current X way and my way is that in the latter, >the comms channel is between functionalities, instead of >functionality-interface-Xserver-interface-functionality. So >functionality retains full control over it's data, and interface does >only what it was designed for - channelling information between >application and user (plus, incidentally, arranging the sharing of >interface facilities through the windowing system). 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. 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. 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. -- Don Dwiggins {scgvaxd,crash}!ashtate!dwiggins