I also weigh a file transfer capability more heavily than the clipboard
transfer. I've been using Timbuktu for years -- its Exchange feature has a
very basic interface (only a single column listing files alphabetically) but
is very robust. An essential element is its Find function. TB2 for Mac has
a bonus Drag n' Drop capability.
I use TB2's Clipboard transfer less often.
Richard Schletty
Schletty Graphics
Design & illustration for print & web publishing.
Desktop publishing support. Network administration.
Saint Paul, Minnesota
[EMAIL PROTECTED] http://www.schletty.com
Vox 651-222-2526
Fax 651-227-1492
> From: Jonathan Morton <[EMAIL PROTECTED]>
> Reply-To: [EMAIL PROTECTED]
> Date: Wed, 27 Jun 2001 12:57:22 +0100
> To: [EMAIL PROTECTED]
> Subject: Re: Clipboard transfer between MACs
>
>>> I haven't been able to do a Clipboard transfer between Macs running Mac OS
>>> 9.x. Is it possible? If so, how?
>>
>> Ok, well, that's not one I know how to handle. I haven't had easy access to
>> an unrestricted MAC in several years now....
>>
>> What I was referring to is that the VNC protocol already support clipboard
>> transfer. I'm surprised if there isn't support in at least one of the MAC
>> servers/viewers combinations, but I really don't know. It works with all
>> combinations of Xvnc and WinVNC, though.
>
> Unfortunately, that's an unimplemented feature in ChromiVNC for the
> time being. I can add it to my TO-DO list if it's a
> commonly-requested feature... Also, I think a number of Mac clients
> don't handle the Clipboard yet either, apart from being able to
> "rapid-type" text from the client Clipboard by sending keypresses
> (this doesn't quite work either, I need to put an anti-overflow
> thingy in the server).
>
> In any case, I'm much more in favour of a dedicated file-transfer
> scheme being added to the RFB protocol, rather than being hacked into
> the Clipboard-transfer stuff. In particular, the Clipboard on most
> systems has some kind of memory constraint, and may not be 8-bit
> clean for content described as "text". Do you really want to spend 2
> hours transferring a file only to find there wasn't enough memory to
> hold it all? Or that the system has munged it, making it useless?
> Or that the server drops the connection as soon as you try, without
> telling you the reason is that it's run out of memory?
>
> Also, the RFB connection would be "locked up" for the duration of the
> transfer, which could be hours for a particularly large file and a
> slow connection. On top of this, different OSes have differing
> amounts of meta-information associated with a file (some, such as the
> Mac, have entire extra data forks as well as file-type information)
> which it would usually be a good idea to preserve in transit (even if
> it is ignored by the recipient). Converting filename conventions is
> child's play compared to converting meta-information.
>
> A further "desirable feature" might be to allow multiple files to be
> transferred in a single session, without having to manually select
> new filenames and destinations for each one. Fair enough, you can
> just as easily make a ZIP or StuffIt or tarball archive and transfer
> that, but what if the required tool isn't on the other end?
> (Different platforms again!) Such a feature is easily handled by a
> sufficiently well-designed protocol, without excessive code bloat on
> either end of the connection.
>
> If you absolutely have to transfer stuff by the Clipboard, there are
> already tools which let you do that without inserting hacks on top of
> the RFB protocol. Base64, UUencode, and so on will make an 8-bit
> file ASCII-clean for transfer. Copy the result into the Clipboard,
> transfer it to the target, and decode it. For something which
> everyone is supposed to implement, I want something cleaner than
> that, and fully cross-platform compatible.
> --
> --------------------------------------------------------------
> from: Jonathan "Chromatix" Morton
> mail: [EMAIL PROTECTED] (not for attachments)
> website: http://www.chromatix.uklinux.net/vnc/
> geekcode: GCS$/E dpu(!) s:- a20 C+++ UL++ P L+++ E W+ N- o? K? w--- O-- M++$
> V? PS PE- Y+ PGP++ t- 5- X- R !tv b++ DI+++ D G e+ h+ r++ y+(*)
> tagline: The key to knowledge is not to rely on people to teach you it.
> ---------------------------------------------------------------------
> To unsubscribe, send a message with the line: unsubscribe vnc-list
> to [EMAIL PROTECTED]
> See also: http://www.uk.research.att.com/vnc/intouch.html
> ---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, send a message with the line: unsubscribe vnc-list
to [EMAIL PROTECTED]
See also: http://www.uk.research.att.com/vnc/intouch.html
---------------------------------------------------------------------
