Linked by Thom Holwerda on Fri 23rd Oct 2009 21:13 UTC, submitted by poundsmack
Thread beginning with comment 390998
To view parent comment, click here.
To read all comments associated with this story, please click here.
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[2]: I really wish they wouldn't
by jgagnon on Mon 26th Oct 2009 14:46
in reply to "RE: I really wish they wouldn't"
I've often wondered why Ethernet couldn't be more pervasive as an interconnect of devices. It would simplify so many things from an IT standpoint and it is plenty fast enough for the majority of devices, especially since you can run 10/100/1000 on the same lines (not sure about 10GB). Heck, 10 GB Ethernet is faster than many (most?) hard drives can keep up with.




Member since:
2005-07-10
While not entirely homegrown inside Apple, I think Zeroconf is a good example, possibly the only example, of a good protocol to come out of Apple.
Link-local addressing
Multicast DNS
DNS Service Discovery
All good standards. Though we have yet to see Stuart Cheshire's vision of Ethernet and/or TCP becoming the standard protocol for all devices (TCP keyboard and mouse anyone?), I think Zeroconf is still a huge success.
The bad example I come up with is resource forks. While adding structured data storage to files isn't a bad idea, the way it was implemented at the file system level made it very difficult to exchange files with non-HFS systems. This might have been what the UNIX guys at NeXT didn't like about BeFS, it had the ability to store extended metadata attributes attached to a file that would be lost in a copy to another file system. If I remember correctly, the address book in an early version of BeOS was implemented using file attributes, which was cool in your walled off BeOS corner of the universe, but if you copied a "Person" file from BeFS to another file system or even tried to send one to another BeFS system using a protocol that didn't support copying file attributes you'd end up with a useless 0 byte file. However, BeFS did support HFS resource forks by storing the raw fork data as a file attribute.