|Home » Products » Reviews » The Bad
Transmit 2.6.2: Point By Point
Transmit in action: two side by side Transmit windows show different data for the same file item.
Cabel Sasser is the design wizard at Panic. He doesn't do the programming; he writes the interfaces.
Transmit in action again: all files have the same name.
Cabel thinks the Rixstep review of Transmit is unfair. He acknowledges that everyone is entitled to their opinion but claims the Rixstep article is in error and asked to be able to refute it point by point.
Let 'er rip, Cabel.
But this point by point refutation was not forthcoming, leading one to wonder if Cabel's correspondence was in fact a subtle attempt at pressure.
Whatever: if Cabel can't review a review, perhaps someone else can. And there's no reason to stop there either: the original review was deliberately sparse; under the new circumstances there's no reason to hold back.
Not that one could ever be exhaustive with the bottomless pit that is Panic and Transmit, but the task is easier than shooting ducks in water, so why not let the reader have fun?
Why Only Version 2.6.2?
Easy: the program has systematically been getting more pathetic, moving from mistake to ridiculous blooper. It's hopeless - quit while one is ahead.
Oops! What have we here? A file with no name at all?
Transmit gets worse - not better - over time.
The Blurb Quote
Why is this important? It should be obvious to anyone capable of reading between the lines, and was included precisely for this purpose.
- 'Really, truly fixed 10.3 bug... Really' implies there is a serious credibility issue.
- The boot volume might appear twice? Seriously: this takes some really dipshit coding to accomplish.
- Network appears in the root? See above.
- Used the wrong computer name? See above.
All in all not promising. The apologetic tone ('really, truly fixed bug') should scare any alert user.
- Refreshes - this is true. They don't work - abysmally. Panic are relying on a 'notification centre' but send the wrong flag when registering as an observer. They're clueless.
Notifications can be sent in a number of ways; the simplest - the incorrect way in this case - is to let the system discard all messages generated while the recipient (Transmit) is inactive. Which means that if something happens in another program, Transmit will not see it.
Refreshes across the network are implemented in a different way and actually work better, not worse - but see below for the catch (with Transmit there is always a catch).
At their very worst, however, refreshes across the network are actually mismanaged worse, not better, than when done locally.
The image at the start of this page shows two Transmit sessions looking at the same file item - and no matter how many times the directories are refreshed, no matter how many times you try the old 'Cabel Sasser software warranty trick' and leave the directory and return, the results are the same: the one session shows a file size of 1,147,698 bytes and the other shows a file size of 0.
There is something very scary about the way these guys (do not) think - or test.
(For even more dirt, see below under 'Follow along'.)
- Ghosted stats - this is again true. The crying shame here is that whilst the open source NcFTP engine they've embedded (they don't do their own FTP programming, thank you) will get them right (watch the status line at the bottom during the transfer) when the FTP transfer is completed Transmit will again show the incorrect stats.
These stats come from Transmit's own internal data model, which because of the flawed coding will often be in error.
- No filters - not much to say here: it's just (sadly) true. The time wasted, if turned into money, becomes a small fortune in no time. Anyone doing serious business will steer clear of Transmit for this reason alone.
- Follow along - again it's sadly true; there's not much to debate. But it actually gets worse: as Panic do not lock the Transmit GUI like they should (they don't understand what 'multithreaded' means) but actually queue all events while busy with a transfer and as these events are defined by coordinates whose owners may change before the end of the transfer, havoc can and will be the result.
An innocent click in the GUI can thus lead to irrevocable destruction: Transmit will not respond or interpret the (mouse) event until the operation completes, at which time new files can be added to the listing or files previously in the listing can be removed, meaning the click is seen as being on a different file name - the ramifications are obvious (and all too well known and all too painful).
What Panic should do - what professional FTP clients do - is lock the GUI. As one is not disposed to accept events, give the user the requisite feedback and disable the queue.
But Panic haven't thought through it at all; they have a background only in 'Macintosh programming' and don't know what 'network programming' is or how it demands good thread management. Even for the best it's not easy, but Panic haven't even looked for the start of the road yet.
A typical example of this - and of how dangerous Transmit can be - occurs when the program attempts to change remote directories. This process can take longer than one would think necessary, and for a number of reasons. The trick is that while Transmit is still in the process of attempting to change directories, the 'Upload' command is still enabled.
Due to unnecessary refresh 'flashes' in Transmit's GUI presentation (which seem to come when you don't need them and never when you do) and the oft misleading status reports at the lower left of Transmit's window it can appear that the program has succeeded in changing the directory when it's still trying to find the remote path.
As the brainiacs at Panic haven't understood how to lock the GUI, the user can easily misinterpret the situation and initiate an upload.
Which given the circumstances is nonsensical: Transmit doesn't even know what directory it's in yet!
Which in turn will provoke an enormously user-friendly diagnostic alert panel from Transmit with the following text:
Can't upload item error -113Witnessing all too many of these unforgivable mishaps leads to the unalterable conclusion that when it comes to programming, Panic simply do not have a clue and never will.
- Multithreaded - yes: all network apps by their very nature are multithreaded. You can't hold up a GUI because you're waiting for a response from across a network. But Panic's solution - unique in the industry so far - is to just say 'to heck with it' and allow anything at any time.
Want to create a new local directory? Fine! Call the Unix system call mkdir, list the newly created directory, and be done with it!
Except mkdir, like almost all Unix system calls, is 'intelligent' - it sends back a 'return code' that tells you if the operation was successful or not.
Panic know nothing of such subtleties: in fact it was Rixstep who pointed this out for Panic way back in the 'old days'. Panic didn't even check if the directory was created - and you were going to trust them with your file transfer?
The Good and the Bad
That at any rate was last time; this time, if the stops are let out, things look worse.
- Good: Transmit does have a nice interface. Cabel himself has done a good job.
- Bad: Why can you click on the 'Connect' button even if you've not selected a server?
- Good: Transmit keeps a log of its session activity in ~/Library/Logs.
- Bad: Unfortunately every new session window you open destroys the log already there and in use by the previous window.
[Found in all versions including 3.2 released May 2005. Click here. Ed.]
- Good: Transmit wants to let you double-click an item 'slowly' to rename it.
- Bad: This is a hot-wired feature: the table view is set to recognise double-clicks (which on directories result by default in a move to that directory) and the 'slow' double-click run by a user-defined timer (created not by Apple but by Panic) and these two snippets can conflict so you get both actions at once: you get the edit field to rename a folder - but before you can whisper 'I wanna Panic baseball cap'  they've gone and changed directories on you.
- Good: Transmit attempts to log back in if a connection is broken.
- Bad: Unfortunately it does this for each response lost from the remote server. If Transmit gets stuck and you click 'Refresh' ten times and nothing happens, Transmit will log in again to your server ten times simultaneously, showing you and ignoring all but one connection (the others are simply 'lost').
- Good: Transmit creates its own directory in /tmp to start any session. This can be used to download files to be previewed.
- Bad: The directory should not be created at the start of the session but whenever it's needed. If the directory is destroyed by another program, Transmit throws a fit, spits out an unintelligible error code, and basically sits on its thumbs and does nothing.
- Good: Transmit can preview remote files.
- Bad: Transmit does this by downloading the files; if you decide you want the file, Transmit copies it to your target directory - but guess what? Your local listing will not show it. Click 'Refresh' all you want - but Transmit will stubbornly deny it's there.
Cabel's answer to this and other issues (a typical EULA software warranty requires the vendor to supply fixes or at least workarounds for a period of ninety days) is to have you leave the directory you're currently in and then return. The mind boggles: as this triggers a code snippet which does the real refresh, wouldn't it be easier for Panic to just invoke the same snippet again? But nothing is ever easy in the Panic camp.
- Good: Transmit can show several columns of file info on both sides.
- Bad: The file sizes Transmit shows in its local listings do not include resource forks.
- Good: Panic are cute when they subtitle the listings 'your stuff.' and 'their stuff.' [sic].
- Bad: The terminology is not consistent: alerts capitalise the captions. Bad one, Cabel!
- Good: Panic are good in that they let you see what the modes are on remote items.
- Bad: Clicking 'Apply' in the Info dialog will advance the selection for no apparent reason. Another minor oversight, Cabel? (And for goodness' sake watch out if you have remote items selected before an upload.)
- Good: Panic create a session log for each run of Transmit.
- Bad: There's no way to turn this session log off. Debugging should be done before a product is released - not after.
- Bad: If you rename a file to overwrite another file with the same name, Transmit casually lists two files with the same name.
- Worse: Stuck with this embarrassing blooper - and despite there being a really easy way out, namely just refreshing the listing - Panic decided instead to outlaw standard Unix file overwrites.
This is perhaps the most unforgivable crime the crack team at Panic have ever committed. Unix file operations were standardised way before either of these pimply faced youths were even born. They're going to redesign Unix for us now? Staggering, absolutely staggering.
Worse still is the disinformation that is spread: Panic tell unwitting users their operations are 'illegal' when they're anything but.
There's no two ways about it (even Panic aren't that dumb): in an attempt to cover up their fumbling ineptitude, they lie.
- Good: Transmit can automatically renew an idle logged out session.
- Bad: Transmit doesn't know if you're connected to the Internet or not - not once you've connected to a remote server. For once a transfer begins, Transmit blindly assumes the connection is good. It will keep on trying to complete the transfer until you tire of waiting and put the sorry beast out of its misery.
- Good: Panic did a good job on the interface. And there is no doubt about this: the interface is straightforward and to the point and functional. And this was Cabel's job. And he did do a good job.
- Bad: Transmit is a wobbly shell around the 'real' FTP code supplied by NcFTP.
Transmit Session Transcript
LibNcFTP compiled for macosx
This is where the real work took place. Initially Panic embedded the command line version inside the Transmit application package, but as time went on and they made money off their product, they bought a licence to the 'real thing'.
All things considered, as all the difficult code was already written for them, it was no mean feat to tie it all together in a consistent Cocoa application. Which makes it all the more astounding how they could ever fail so grandly at so trivial a scheme.
When Cabel asked quasi-innocently if he had ever done anything to incur the wrath of Rixstep, he was told that years earlier Rixstep had submitted a long list with the above bugs and others, and that the list was summarily ignored, resulting only in software warranty tricks like 'leave the directory and come back'. Perhaps Cabel has now found that list again; odds are however that nothing will ever come of it.