Re: Clipboard Daemon - thinking of writing one :)
Robert Watson [EMAIL PROTECTED] wrote: - How can I choose a guaranteed free TCP port? www.iana.org IANA -- Internat Assigned Numbers Authority This is fine in theory, but doesn't work quite as well in practice. I spent several years (unsuccessfully) trying to convince a sister company that allocating TCP ports starting at 6001 for an application was not a good idea (the system _did_ include an X-server, but not multi-headed, luckily). It made using ssh quite a pain at times. Orbix (IONA's CORBA implementation) uses a number of TCP ports - none of which seem to be registered. Closer to home, there's the recent problems with the RADIUS ports. Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Clipboard Daemon - thinking of writing one :)
Robert Watson rob...@cyrus.watson.org wrote: - How can I choose a guaranteed free TCP port? www.iana.org IANA -- Internat Assigned Numbers Authority This is fine in theory, but doesn't work quite as well in practice. I spent several years (unsuccessfully) trying to convince a sister company that allocating TCP ports starting at 6001 for an application was not a good idea (the system _did_ include an X-server, but not multi-headed, luckily). It made using ssh quite a pain at times. Orbix (IONA's CORBA implementation) uses a number of TCP ports - none of which seem to be registered. Closer to home, there's the recent problems with the RADIUS ports. Peter To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Clipboard Daemon - thinking of writing one :)
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
Re: Clipboard Daemon - thinking of writing one :)
On Thu, 8 Jul 1999, Mikhail Ramendik wrote: 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. This is why Private Name Spaces are a good thing. They act like a file system (because they are a file system), they can be backed by a file system or whatever you wish (i've got both memory servers and file system servers) and they allow processes to create shared, private data to support such things as a clipboard. You don't need to write a special daemon, you just need to get private name spaces working on freebsd. I have a first piece in the v9fs file system, which is a memory file system but which is intended to support private name spaces in the future. Note that private name spaces work just fine over a network. ron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Clipboard Daemon - thinking of writing one :)
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
Re: Clipboard Daemon - thinking of writing one :)
You might also want to look a GNUstep ( www.gnustep.org ) as well. stef You wrote: - 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. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Clipboard Daemon - thinking of writing one :)
On Thu, 8 Jul 1999, Mikhail Ramendik wrote: 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. This is why Private Name Spaces are a good thing. They act like a file system (because they are a file system), they can be backed by a file system or whatever you wish (i've got both memory servers and file system servers) and they allow processes to create shared, private data to support such things as a clipboard. You don't need to write a special daemon, you just need to get private name spaces working on freebsd. I have a first piece in the v9fs file system, which is a memory file system but which is intended to support private name spaces in the future. Note that private name spaces work just fine over a network. ron To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Clipboard Daemon - thinking of writing one :)
The hard part is going to be the applications to co-operate. good luck. it's be nice. especially if it worked with the syscons cut-n-paste. julian 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. 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. 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 - Whether a similar solution already exists in the freenix world (perhaps in Linux?) - 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? Yours in Christ, Mikhail Ramendik Moscow, Russia To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
