[Chris Grande]

Originally posted by lookmark:
Why, Apple's even left a nice little space to the right of the pull-down menu....

Seems they had the same idea, here is a screenshot from the Paris Expo Keynote:

[nforcer]

Originally posted by Chris Grande:
Seems they had the same idea, here is a screenshot from the Paris Expo Keynote:

Good catch.

[Chris Grande]

Also the build number in Paris was 8A244 as of Aug 31st. (From someone on the AppleInsider forums who was there).

[xmacintosh]

I have a question about Mail in 10.4: can I send html mail using Mail.app? Thanks.

[CharlesS]

Originally posted by diamondsw:
Are you actually rolling on the floor, giggling with glee until your ass magically falls off?

Well, I can't say that, but comments like this do make me chuckle a bit.

[WJMoore]

Originally posted by xmacintosh:
I have a question about Mail in 10.4: can I send html mail using Mail.app? Thanks.

Yes it does, this was most recently mentioned in the Paris keynote.

[JellyBeen]

Originally posted by freeandunmuzzled:
and when you make a new folder in column view and rename it, it stays at the bottom of the list for a while rather than immediately moving into alphabetical order. just like that other OS...

[WHINE]BTW, is it just me, or is anyone else annoyed at the advance of the blue everywhere in OS X? I use the 'graphite' appearance and I think ALL blue stuff shoudl change to graphite. instead I have to suffer nasty blue highlights in the finder sidebar in Panther, and when I turned on graphite in Tiger the damn spotlight corner stayed blue.[/WHINE]

Would you like for me to add a little cheese and crackers with your Whine??

[Brass]

Originally posted by Stradlater:
FTP via web browsers are also read-only; while expanding the Finder FTP would be nice, there are alternatives right now, and other more important, more exciting things that need to be worked on in the OS.

This logic is a little flawed.

Firstly, web browsers are read-only for local disk file system browsing too. So I don't think we should assume the the Finder should follow the behaviour of web browsers for anything. Web browsers are for (believe it or not) browsing. Whereas the Finder (although perhaps not entirely well named) is for managing files on a wide variety of mediums (local disks, network shares, etc). It is inconsistent for the Finder to be able to read/write every other medium, but not FTP. Sure, there are some other instances where the medium is write protected, but that is not because of the Finder's restriction, that is because of the medium's own restrictions (eg, CD-ROM, local disks with restricted permissions, etc).

As for "more exciting things that need to be worked on in the OS", whether it's true or not, by that logic, this feature would probably NEVER get done. There must be a better way for Apple to prioritise tasks that by how exciting some users think they are. Since the Finder has had FTP capabilities for some time now (Jaguar, I think?), its rather negligent of Apple not to have "finished" that implementation, particularly when such a task is relatively simple and easy for them to implement.

[Gavin]

Originally posted by Brass:
This logic is a little flawed.

Firstly, web browsers are read-only ... Web browsers are for (believe it or not) browsing. Whereas the Finder (although perhaps not entirely well named) is for managing files on a wide variety of mediums (local disks, network shares, etc). It is inconsistent for the Finder to be able to read/write every other medium, but not FTP. ....

Since the Finder has had FTP capabilities for some time now (Jaguar, I think?), its rather negligent of Apple not to have "finished" that implementation, particularly when such a task is relatively simple and easy for them to implement.

My guess is that it has to do with user experience. FTP is very slow compared to mounted volumes and especially local files. It may not integrate with the finder the way a real file sharing system can. For instance you can't preflight a file transfer to see if there is enough room on the remote disk to hold your file. Some FTP servers yes, but you can't count on it.

Spending ten minutes writing a file to a floppy only to have it run out of room and die is the kind of crap that made windows such a joke. That alone may make it unacceptable to apple's QA guys.

Apple has a habit of cutting off the low end in the name of good user experience, you can see it in iChat. iChat AV WILL work on a 350Mhz g3 but it's slow and flaky so they won't let you use it. They would rather have people grumbling that they don't have a feature than have people use it and think it sucks.

I would rather they just have a warning saying 'hey, your system does not have the balls to run this app at full speed, you can use it but it will be sucky.'

[Brass]

Originally posted by Gavin:
My guess is that it has to do with user experience. FTP is very slow compared to mounted volumes and especially local files. It may not integrate with the finder the way a real file sharing system can. For instance you can't preflight a file transfer to see if there is enough room on the remote disk to hold your file. Some FTP servers yes, but you can't count on it.

Spending ten minutes writing a file to a floppy only to have it run out of room and die is the kind of crap that made windows such a joke. That alone may make it unacceptable to apple's QA guys.

Apple has a habit of cutting off the low end in the name of good user experience, you can see it in iChat. iChat AV WILL work on a 350Mhz g3 but it's slow and flaky so they won't let you use it. They would rather have people grumbling that they don't have a feature than have people use it and think it sucks.

I would rather they just have a warning saying 'hey, your system does not have the balls to run this app at full speed, you can use it but it will be sucky.'

But FTP is lightning fast compared to AFP. AFP is slothful.

As you say, being able to determine if the file system is going to fill before starting to write the file could be an issue, but that's about it. And you can't even guarentee that for local file system, let along network file systems - it's still just a guess (depending on what other activity might happen while the file is being written).

[Simon]

Can anybody here with the Tiger DP tell me if Preview can finally handle PDF forms correctly?

If I get a PDF form in Panther the PDF Browser Plugin and Adobe Reader display and print the form entries. Preview doesn't.

Has this nasty bug been fixed in Tiger's Preview.app?

[JLL]

Originally posted by Brass:
But FTP is lightning fast compared to AFP. AFP is slothful.

Huh?

[Brass]

Originally posted by JLL:
Huh?

You think AFP is fast?

[Gavin]

Originally posted by Brass:
But FTP is lightning fast compared to AFP. AFP is slothful.

Maybe for actually moving the file. FTP takes more effort to connect and get info for every little transaction, it is basically a command line tool. You send commands to the server one at a time - log me in, list this directory, send me this file. People talk about AFP being chatty, I'd guess an FTP session is even more so. More importantly it doesn't send info until you ask for it. People already bitch about the finder not showing instantly that their files have been updated by some program or other.

As you say, being able to determine if the file system is going to fill before starting to write the file could be an issue, but that's about it.

That alone could be the deal killer.

And you can't even guarentee that for local file system, let along network file systems - it's still just a guess

With FTP you can't even rely on getting the guess.

I'm guessing they tried it and the experience was worse than connecting to an iDisk over 56K, so they bagged it. It's one thing to sit and wait with an FTP client but people's expectations for the Finder are different.

Don't get me wrong here, I WANT full ftp in the finder. I just think this is the most reasonable explanation of why it's not there. "It's because they don't want to hurt sales of Transmit" doesn't cut it considering Apple's track record. (sherlock,etc.)

[JLL]

Originally posted by Brass:
You think AFP is fast?

I have no problems with it.

[Brass]

Originally posted by Gavin:
Maybe for actually moving the file. FTP takes more effort to connect and get info for every little transaction, it is basically a command line tool. You send commands to the server one at a time - log me in, list this directory, send me this file. People talk about AFP being chatty, I'd guess an FTP session is even more so. More importantly it doesn't send info until you ask for it. People already bitch about the finder not showing instantly that their files have been updated by some program or other.

I don't think FTP is much more chatty than any other file sharing protocols. All of them require a login, and all of them require a directory listing command (with FTP, and single command, "ls -l" will give you full details of all files in that directory), and all of them require commands to perform actions (read/write/delete, etc).

FTP is not a command line tool, it is a protocol (in the same way that POP or SMTP are protocols, not tools). It can be ustilised by a command line tool (or by a GUI tool).

[Gavin]

Originally posted by Brass:
I don't think FTP is much more chatty than any other file sharing protocols. All of them require a login, and all of them require a directory listing command (with FTP, and single command, "ls -l" will give you full details of all files in that directory), and all of them require commands to perform actions (read/write/delete, etc).

FTP is not a command line tool, it is a protocol (in the same way that POP or SMTP are protocols, not tools). It can be ustilised by a command line tool (or by a GUI tool).

It is a ~30 year old protocol designed to be used by a command line tool, The GUI's ( which started showing up some 15 years later) are wrappers for the command line tool and still send the same long commands spelled out in english.

I believe with FTP there are a lot more actual bits going between client and server for each transaction. It's just not designed like file sharing systems which are in constant contact between client and server automatically sending useful status info back and forth every few seconds. FTP servers only delivers stuff on demand from the client.

FTP: packet data + some command spelled out in english (roughly)

stuff like this is actually sent :

226 Transfer complete.
214 bytes received in 0.018 seconds (11 Kbytes/s)
ftp> cd rfc
250 CWD command successful.
ftp> get rfc1048.txt.gz
200 PORT command successful.
150 Opening ASCII mode data connection for rfc1048.txt.gz (5141 bytes).
226 Transfer complete.
local: rfc1048.txt.gz remote: rfc1048.txt.gz
5161 bytes received in 1.6 seconds (3.2 Kbytes/s)
ftp> quit
221 Goodbye.


as opposed to

file sharing: packet data + minimal binary codes

This happens farther down in the bowels of the networking stuff and sends terse binary messages. So every step, logging in, listing files, etc., is faster.


They are two completely different animals and they are going to act differently if you roll them into the finder.

Another thought occurred to me, the finder might just be such spaghetti code that adding in 2 way FTP would just plain be a bitch. NFS,AFP, SMB, even WebDAV can all be handled as actual file systems, the finder doesn't handle the connections, the system does.

[z|gzag]

Originally posted by Gavin:
Another thought occurred to me, the finder might just be such spaghetti code that adding in 2 way FTP would just plain be a bitch. NFS,AFP, SMB, even WebDAV can all be handled as actual file systems, the finder doesn't handle the connections, the system does.

It can be implemented by an FTP FS module, such exists. But really, FTP will still be slower you're right. Personally, I don't need it, but would still be nice to have FTP work well because many sites only offer FTP access.

[Brass]

Originally posted by Gavin:
It is a ~30 year old protocol designed to be used by a command line tool, The GUI's ( which started showing up some 15 years later) are wrappers for the command line tool and still send the same long commands spelled out in english.

A good FTP GUI is NOT a wrapper around a command-line tool at all. Yes, it sends and receives protocol commands, but this is very different from a command-line tool wrapper. That's like saying your email POP client is just a wrapper around a command line tool.

ALL client/server process pairs send information back and forth to each other (how else can they communicate). The fact that these commands are sent as plain ASCII strings doesn't make FTP a command-line tool. The command line versions of FTP produce ASCII strings and send them off to the server. The GUI versions of FTP produce ASCII strings and send them off to the server. This doesn't make the GUI FTP tools wrappers around command-line tools.

I'm not trying to imply here that FTP is better or worse than anything else, but simply that FTP is NOT a command-line tool. It is a protocol. And GUI FTP clients are NOT necessarily wrappers around command line FTP tools.

I believe with FTP there are a lot more actual bits going between client and server for each transaction. It's just not designed like file sharing systems which are in constant contact between client and server automatically sending useful status info back and forth every few seconds. FTP servers only delivers stuff on demand from the client.

"constant contact between client and server" makes it sound like the non-FTP protocols are more "chatty"?

[sambeau]

Originally posted by Gavin:
It is a ~30 year old protocol designed to be used by a command line tool, The GUI's ( which started showing up some 15 years later) are wrappers for the command line tool and still send the same long commands spelled out in english.

I believe with FTP there are a lot more actual bits going between client and server for each transaction. It's just not designed like file sharing systems which are in constant contact between client and server automatically sending useful status info back and forth every few seconds. FTP servers only delivers stuff on demand from the client.

FTP: packet data + some command spelled out in english (roughly)

stuff like this is actually sent :

226 Transfer complete.
214 bytes received in 0.018 seconds (11 Kbytes/s)
ftp> cd rfc
250 CWD command successful.
ftp> get rfc1048.txt.gz
200 PORT command successful.
150 Opening ASCII mode data connection for rfc1048.txt.gz (5141 bytes).
226 Transfer complete.
local: rfc1048.txt.gz remote: rfc1048.txt.gz
5161 bytes received in 1.6 seconds (3.2 Kbytes/s)
ftp> quit
221 Goodbye.


as opposed to

file sharing: packet data + minimal binary codes

This happens farther down in the bowels of the networking stuff and sends terse binary messages. So every step, logging in, listing files, etc., is faster.


They are two completely different animals and they are going to act differently if you roll them into the finder.

Another thought occurred to me, the finder might just be such spaghetti code that adding in 2 way FTP would just plain be a bitch. NFS,AFP, SMB, even WebDAV can all be handled as actual file systems, the finder doesn't handle the connections, the system does.

What are 20 bytes when a small image takes up a couple of thousand and normally transfers in a fraction of a second?

Underneath all UNIX based protocols is a lot of good-old-fashioned text - HTTP for instance (telnet into any webserver on port 80 and you can see this for yourself) - and now that we're all going XML we aren adding even more text to our data - but just a few bytes here and there. It really doesn't make much of a difference in these broadband days.

eg goto the terminal and type

Code:
telnet www.apple.com 80
GET /

you send text - you get text. It's the simplicity that has made it universal: easy to test, easy to debug and easy to write white papers about it..

[sambeau]

Originally posted by Brass:
A good FTP GUI is NOT a wrapper around a command-line tool

But it could be..

[DVD Plaza]

Originally posted by Gavin:
226 Transfer complete.
214 bytes received in 0.018 seconds (11 Kbytes/s)
ftp> cd rfc
250 CWD command successful.
ftp> get rfc1048.txt.gz
200 PORT command successful.
150 Opening ASCII mode data connection for rfc1048.txt.gz (5141 bytes).
226 Transfer complete.
local: rfc1048.txt.gz remote: rfc1048.txt.gz
5161 bytes received in 1.6 seconds (3.2 Kbytes/s)
ftp> quit
221 Goodbye.

as opposed to

file sharing: packet data + minimal binary codes

This is how many systems work behind the scenes. When you use your fancy e-mail program to receive e-mail what do you think is really happening behind the scenes? Here's a manual example of talking to a POP3 server:

telnet mail.server.name 110
user username
pass password
list
retr 1
retr 2
retr 3
retr 4
retr 5...etc
quit

You can manually talk to SMTP as well, HTTP if you want, and yes as you say FTP... so what if they talk with english behind the scenes instead of stupid proprietary codes? Far simpler, universal, and open than something like:
%*@&*^@&*%rfc%$&)@@#^&%^$*&rfc1048.txt.gz%&)#@$&#% ^$&^Y*($(%

[jocker]

Dear oh dear you guys have lost the plot. All these protocols (HTTP, FTP, POP) etc only return data based on a client request... There is server NO push technology. Hence why AFP is preferable for a filesystem.

Sometimes you can't see the wood for the trees.

I know I've got a low post count, so I'll either get ignored or spat on.

[Brass]

Originally posted by jocker:
Dear oh dear you guys have lost the plot. All these protocols (HTTP, FTP, POP) etc only return data based on a client request... There is server NO push technology. Hence why AFP is preferable for a filesystem.

Sometimes you can't see the wood for the trees.

I know I've got a low post count, so I'll either get ignored or spat on.

That's fine, and I agree in most circumstances (except that I find AFP over the internet to be very slow).

However, I think the origin of this argument was that the Mac OS X Finder does implement both, and should improve it's FTP implementation to be read/write, and not just read only. The argument (I think) was to validate that FTP should be able to be used by the Finder in this way.

But I maybe wrong... the argument is very old and I can't be bothered reading it all again .

[tooki]

1. The old argument (which wasn't ever really true) was that AppleTalk was chatty -- NOT that AFP (Apple Filing Protocol) is chatty! Nowadays, AppleTalk isn't used, but TCP/IP instead, even for AFP.

2. I would expect that AFP (like any other network filesystem, e.g. NFS, SMB, AFS, etc) is a lot chattier than FTP. An FTP server does not send updates -- it strictly responds to requests from the client. A network filesystem needs to be able to tell the client about changes without the client asking first. This status notification will necessitate some extra network traffic. *

3. AFP was designed for reliable, low-latency connections, which is why it runs poorly over the Internet, where latency is often very high, and packet loss occurs. AFP is extremely poor at recovering from lost packets. FTP, on the other hand, handles those cases much better. Apple ditched AFP for WebDAV for iDisk because WebDAV also handles high latency and packet loss MUCH better, resulting in roundabout better performance.

tooki


Edit: *Everyone in this argument should first look up the difference between a file transfer protocol (i.e. FTP, TFTP, or even HTTP) and a network filesystem. They are NOT the same thing, and really can't be treated the same way. It is possible to mush one into working sorta like the other, but it usually only works so-so.

[Bogartte]

I thought of something that would be really neat in Tiger. I tend to gather lots of links and files on my desktop, and it soon gets cluttered: the ability to have two desktops, one as cluttered as ever and a nice clear one. The clear one would always be in view, and when I drop a link, or file to it, it automatically goes to the other, hidden desktop... which I can switch to with an F keystroke.

Good idea, or stupid? I suppose I could clean it up and just have one folder on my desktop, and drop everything into it, huh?

[jocker]

Edit: *Everyone in this argument should first look up the difference between a file transfer protocol (i.e. FTP, TFTP, or even HTTP) and a network filesystem. They are NOT the same thing, and really can't be treated the same way. It is possible to mush one into working sorta like the other, but it usually only works so-so.

My Point Entirely!!

[jocker]

Originally posted by Bogartte:
I thought of something that would be really neat in Tiger. I tend to gather lots of links and files on my desktop, and it soon gets cluttered: the ability to have two desktops, one as cluttered as ever and a nice clear one. The clear one would always be in view, and when I drop a link, or file to it, it automatically goes to the other, hidden desktop... which I can switch to with an F keystroke.

Good idea, or stupid? I suppose I could clean it up and just have one folder on my desktop, and drop everything into it, huh?

hmm.. maybe. Not convinced though. I think using the desktop as a storage location (i.e. default download location etc) is a bit long in the tooth. With tiger, you'll be able to find anything instantly, so storage location is going to be a non-issue. I personally believe that the desktop should be used as a temporary 'shelf' just whilst your moving files etc. Its a difficult one this actually. I often find myself tidying up my desktop around once a week, and I often delete important files by accident purely because they are 'cluttering' up my desktop. I think that no app should put files there by default.

So come on - thoughts on the desktop and whether the desktop metaphor is going in the right direction.