Date: Thu, 8 Jul 1999 05:58:39 -0400 (EDT) From: Robert Watson <robert@cyrus.watson.org> To: Mikhail Ramendik <mikhram@dataforce.net> Cc: freebsd-hackers@freebsd.org Subject: Re: Clipboard Daemon - thinking of writing one :) Message-ID: <Pine.BSF.3.96.990708054657.17458C-100000@fledge.watson.org> In-Reply-To: <003d01bec8f9$feeadf90$8fa02ac3@ramendik>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 8 Jul 1999, Mikhail Ramendik wrote: > Hello! > > I am new to FreeBSD and Unix, but not new to programming and TCP/IP. > > I have noticed that there is no good clipboard system in FreeBSD. X has > only a rudimentary clipboard, and outside X there is no clipboard that > would be shared between programs... All this while Windows has a very > interesting clipboard system that allows to paste as different types. Retrofitting this kind of thing will almost certainly be hard: Microsoft has the advantage of writing the toolkits used by their application developers, and getting to change the rules at any point in time. Similarly, Microsoft hasn't delivered the network services that you describe below, either. :) Microsoft also has the advantage of being able to liberally mix the operating system and application space. In UNIX-land, the entire windowing system and toolkits on top are replaceable, meaning that there is more flexibility, but fewer standards other than de-facto standards. Consider instead placing your work in the context of an object system (see below) such as GNOME or KDE. > I am thinking of writing a Clipboard Demon (of course, free and > documented and source and all) to try and tackle this problem. It's > going to be a daemon working over IP, it will allow "named clipboards" > so that by default each user has one clipboard, but a user can start > several clipboards and/or share one over a network (ok, insecure, at > least in first releases - but then, it can be nonsensitive info over a > LAN). It will allow a program to export data into the clipboard in one > or _several_ formats (MIME, of course), and then it will allow the > importing program to choose the format it wants (a la Windows, but no > OLE stuff here) and get the data in it. Security will be an issue here. The traditional way to do this kind of thing is in the context of an existing distributed system of some kind, relying in its services for connection management, data format management, etc. A few considerations you might want to examine would be single-host security (who owns what data, when can different things be copied, pasted -- xterm runs as root, your shell runs as you, your X server runs as root, etc, etc), multi-host security (cryptography, mapping users between systems, existing distributed authentication schemes (kerberos, for example), etc), and access control -- will you have shared clipboards? > For example, a GUI text editor can export the text as native format, > text, formatted text (RTF?), vector graphics (unsure what format would > replace WMF here), bitmap. This same editor will paste the native by > default, another editor will use the formatted text by default, etc. > > Note that it will work independently of X. So I can copy in Joe then > paste to GIMP (as text), if both support the clipboard. > > I will probably have time for actual coding in August or September. But > I want to work out the specs first, and to make sure it's needed at all > ;) So, my questions are: > > - Whether this thing is, in your opinion, needed It sounds extremely useful. Network support is something that would be very nice to have, although you may be replicating work in distributed file systems. It might be worthwhile to consider whether an existing distributed file system might be a better time investment (Coda, AFS/Arla, etc) because it would provide a decent transport with a namespace, authentication, ACLs, etc. > - Whether a similar solution already exists in the freenix world > (perhaps in Linux?) Might want to look into the various distributed object models being considered (don't both the KDE and GNOME people have some interest in this?). I don't know much about them (KDE uses CORBA maybe?), but the chances are they have at least begun to address some of the complicated issues that you would need to look at. > - How to handle "big" data? If a program exports a big graphic in several > formats, that's a lot of data... Well, it can not actually send the data but > only indicate it's available - but then we'd have to "call back" to receive > the data, so the program would need to have a permanent connection with the > daemon and "listen" to it, and the availability of data would cease when the > program quits. Should I nevertheless include this behaviour as an option, to > be decided by the exporting program? > > Now the newbie questions: > > - Where can I read a good text on writing FreeBSD daemons? > > - How can I choose a guaranteed free TCP port? www.iana.org IANA -- Internat Assigned Numbers Authority > Yours in Christ, Mikhail Ramendik > Moscow, Russia Your project sounds interesting, but I suspect that you may want to reconsider your approach. It might make more sense to have a distributed database or network accessible database capable of managing typed data, access control, authentication, etc, and then a local daemon that communicates with it, as well as to library hooks in applications via file system socket capable of passing local credentials for authomatic local authentication. You could have a small X program that hooks the current X selection space (for easy interaction with existing text X applications), and then a library that could be linked into more complex applications that would provide some standard clipboard services by connecting to the local clipboard management daemon. I suspect however, this is not an easy project, and looking at existing distributed object systems may be a better way to go, along with a little adapter application that works with the X selection to provide legacy application support. Sounds fun. Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Computing Laboratory at Cambridge University Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.990708054657.17458C-100000>