I know the issue of synchronization has been brought up a few times by users like myself who like to keep a given database in more than one computer in identical state. As of now, in my understanding, the only way to achieve this is by brute force copy and replace - which is extremely inefficient way to do it. It has also been said that size limitations of .mac would make it impractical to use it for this synching purpose. I am wondering if this could be addressed if the synchronization feature works primarily by sync-ing the daily changes done to a database through the history it already keeps. Since the daily modifications are often of manageable size to sync it can fit in with the main purpose of .mac.
To begin with, one might copy the database to all computers the user uses, and sync-feature can merely keep them all up to date. It could warn the user if ‘too much’ modification has been done to the database than it could handle through .mac - in which case the user would have to resort to manual sync.
I too am not sure exactly how this should work, as thousands of PDFs aren’t something I would want to be clogging up .Mac with. But I agree heartily that some kind of synch would be really wonderful. One idea that comes to mind is to have a .Mac folder in your database, into which you would put replicants of things that you wanted synched. Optionally DT could offer an even quicker way than the present contextual menu to choose documents to be synched. This approach is similar to the StickyBrain one.
I understand that would be impractical. That is why I thought synchronizing the daily updates to .mac and vice versa from your other mac would keep them in sync. This would work really well for the 1001th PDF or any other stuff you added somewhere in DT database. For me the best part of DT is I don’t need to diligently keep track of what I put where. That is why I am relucatant for a specific .mac folder which would mean you have to constantly keep making decisions like ‘am I sure I want/ don’t want to access this on my other computer now/later??’. I am not very good at that decision making- and that’s why I like DT pro so much!!
spyder
spyder:
Your comments indicate a good understanding both of the potentials and problems of using .Mac as a database synchronization medium.
It’s great that Apple has raised .Mac user accounts to 1 GB. That makes it more useful for many purposes. Now it’s big enough that I could actually use it to store archived backups of some of my DT Pro databases (but not my main database – it’s still too small for that). Note that I’m talking here about single archive files created by DT Pro’s Backup Archive script, not about actual uncompressed databases, which may contain a great many files.
The real problem with .Mac – and it is a killer for some potential uses – is that it is SLOW.
Performance isn’t too bad if one sends to .Mac a single 6 MB archive file. It may take minutes to do that. But if one sends over a 6 MB folder containing many files, .Mac transfer rate really slows down – multiples of the time required for a single file of the same 6 MB size.
If you read user comments about how one can manage uses of a database on more than one computer, generally a desktop and a PowerBook or iBook, you will see a number of approaches. Maria, for example, doesn’t really try to synchronize her desktop and PowerBook. If she uses the database on the PowerBook and adds material, she generally uses the History tool to identify and export the content added to the PowerBook, and then sends that back to the desktop computer that manages her main databases. I sometimes use the same approach.
Personally, when I’m on travel I prefer running my databases off a portable FireWire drive. I was in Europe last week attending DEVONtechnologies meetings. I simply copied my databases to a FireWire drive, and didn’t even bother to take along my PowerBook, as I could use local computers running DT Pro. Using DT Pro, I run my databases directly on the portable drive, so I don’t have to worry about leaving sensitive information on someone else’s computer. On returning home, all I had to do was copy modified databases back to my iMac and PowerBook. As my tiny FireWire drive weighs about 4 ounces and fits in a shirt pocket, it’s the best thing since sliced bread for running my databases on travel and easily updating my ‘at home’ computers.
Even when I travel with my PowerBook, I run my DT Pro databases directly on the FireWire drive (possible, but not simple to do using DEVONthink PE). That drastically simplifies all issues of updating the databases on my two computers. Needless to say, my databases are too large to fit on .Mac. Even my smallest databases would take much too long to transfer to and from .Mac to be considered usable that way. And using synchronization techniques on .Mac – although possible – would require much more work and time.
I use .Mac for lots of things, but not for synchronizing my DT Pro databases. My FireWire drive cost less than $100, and will be 4 years old next month. With an annual amortized cost of less than $25, it’s the fastest and simplest way I’ve yet found for running my DT Pro databases on multiple computers with an absolute minimum of effort to keep them current on my two computers.
Yes, future versions of DT/DT Pro will make it simpler to use synchronization techniques. But unless Apple modifies .Mac considerably, it will remain a slow transfer vehicle. I’ll readily confess that I just don’t have the time and patience to use .Mac for synchronizing my DT Pro databases. 
Bill:
Thanks for the clear and detailed response.
If one wants to transfer entire database or very large chunks of info, firewire drive is the way to go. I am totally with you on that - in fact, my 40gb iPod (Portable Omnipotent Device!) is the donkey that carries my 2Gb database to and fro, currently.
However, it is not only a manual chore that one has to ‘remember’ and actively do, it also is inefficient since it is a circuitous process involving mounting the disk, going to history, exporting it, unmounting and the whole process reversed at the other computer. Not impossible at all - just completely automatable from within DT, if it would support a sync service. IMHO an average user’s DAILY modifications might rarely exceed 25 Mb (an arbitrary guess). Since web based synchronization have the advantage of running in the background at specified intervals (just like Mail for instance) the process could be completely transparent to the user. Agreed, now when you go home to the other computer, if you immediately need the updates, you may need to wait the 3-4 minutes it might take. On the other hand, if you happen to check your emails or read the headlines while DT is launching, your updated database would be waiting when you are ready! What if I went crazy on one computer and made too many changes amounting to a size that is impractical for web based synchronization service? Well DT can figure that out and tell the user up front - “Hey you have overwhelmed the sync service, so you better manually bring the database on the other computer up-to-date. From there on I will take over again”.
Of note, I am not totally married to .mac- I mean a web based synchronization service such as .mac. And two, this may be feature that just seems easily implementable in my head and in reality a nightmare for those who actually need to code for the changes. If so I will keep my mouth shut and keep doing what I have been for a while - fire up the iPod!
Hi, spyder:
Note that when I’m on travel I avoid the time and effort of selecting new additions in History, exporting them, then importing them into another database.
I just run my DT Pro databases directly on my FireWire drive. Yes, you can do that on an iPod, as well (though I’m not sure how fast the new iPod nano would be – and of course the nano doesn’t have much room for database files).
I do this even if I’m carrying along my PowerBook. My 4-ounce FireWire drive and FireWire cable fit easily into my PowerBook’s traveling case and don’t add significant bulk or weight.
Admittedly, my FireWire drive is a bit slower than my internal drives, but performance is quite acceptable. And the sheer simplicity and convenience of this approach is why I like it.
When I get back home I have to remember to do one step: replace the old database on my iMac with the modified database on the FireWire drive. That’s no more difficult than having to remember to synchronize the databases via some other method. Of course, as a quality assurance precaution, I run Tools > Verify & Repair followed by Backup & Optimize on the FireWire database before copying it to my iMac. But I should do that before any other synchronization method, anyway.
Bill, A little OT, but what do you know about using an iPod as a portable FW? Which I’ve always used, don’t know why everyone doesn’t–need a replacement, why wouldn’t an iPod function as a portable FW storage/backup drive (I understand, not to drive an OS)?
zo
Hi, Zo:
Most iPod models work fine as FireWire drives, even the 5 GB first generation model.
The iPod nanos are flash based, so I’m not sure how fast they would be (and they have less storage space, and use USB 2.0).
Zo,
Ipods were never designed to be used as working external drives, (as opposed to backup drives)During normal use songs load into a large buffer to cut down on drive access. Any setup that constantly accessed the drive would probably make for more wear and tear than the design allowed for and thus shorten the lifespan of your Ipod.
Cheers,
Eiron.
Huh? The iPod (except the Shuffle and Nano) are just hard drives: IFRC the firewire (or USB 2.0) access doesn’t go through the RAM buffer at all: it’s there for music, but not hard drive access. It’s as fast (and durable) as a hard drive as any other tiny external firewire drive. That it’s an iPod should have nothing to do with the lifespan, nor its usability as an external drive.
For some anecdotal evidence, I used my 1st gen iPod as a full-time external drive for years with no ill effects (except for a completely unrelated scroll wheel problem). Battery life is still excellent. My newer 4th gen iPod has also experienced no negative consequences from extensive hard-drive use (both backup and live drive use).
I have even run DTPro databases (small ones) off a Shuffle successfully. If you’ve got an iPod, use it. Get your money’s worth for that otherwise one-trick-pony.
–jw
I didn’t mean to imply that you couldn’t run DT off an Ipod; on the contrary I keep backups on my 20 gig ipod AND my shuffle. Of course it’s just a hard drive.
Nonetheless IPODS are rated at 20,000 hours while desktop drives are usually rated to 750,000 hours or more. Moreover excess heat in that little case will eventually fry the sucker. Even APPLE has said that using an IPOD as a startup Drive, for instance, will shorten it’s lifespan.
Nevertheless I’m not a techie and I have no intention of implying that I personally know what the hell I’m talking about… Just thought I’d pass on what I’ve heard, and read, for what it’s worth- which apparently isn’t much. 
BUT you needn’t take my word for it, Google something like “IPOD as hard drive” and there 's plenty of evidence anecdotal and otherwise on the internets.
Cheers
Eiron
On use of iPod as a hard drive for running databases: Everyone is right.
I really don’t use my iPod often as an external HD for running DT Pro databases. It’s not as rugged as larger portable FireWire drives, and I would recommend a good portable drive for those who frequently run databases on travel, or sharing home/office computers.
Still, 20,000 hours is a long time. I wouldn’t worry about a few hours here and there while on travel. Using an iPod as a bootable drive does stress the heck our of it, but running a DT Pro database isn’t all that stressful.
I’ve got a FireFly drive that uses an iPod HD, but in a magnesium enclosure. It runs cool – probably much better cooling than in the iPod enclosure. I’ve been using the FireFly drive for almost 4 years and never a problem. I’ve got another external FireWire drive that has larger capacity and is built like a tank by comparison – but the FireFly is my usual travel companion.
One already possible way to improve & simplify this is to use the script “Scripts > Export > Backup Archive…”. This will create a zip archive of an optimized & verified database (without additional backups but containing all files copied to the database package). Therefore you have to copy/upload/download only one file which is also smaller.
Hi, instead of synchronization, why not multi-user? I think DevonThink Enterprise will addess this.
I have a big user of MarketCircle Daylite. It runs of my PB, so I always have everything when I travel. And at the office when I use my iMac, it simply uses the data on the PB. Fast, no hassle.
Thanks
One of these days. 
I voted “not really”—since the option “not at all” was not on offer—because my databases are larger than 1 Gb, and I do not use .mac, two reasons not to support the suggestion.
I have long used MO drives for BackUp purposes—extremely reliable medium. But the files I now need to backup are getting too large, unfortunately.
Adding to the script to subsequently and automatically transfer (backup) the .zip archive to my iDisk would be delightful.
The problem would be failure potential because of insufficient space on one’s iDisk. For that reason, DEVONtechnologies would be reluctant to replace the existing script with a change to iDisk storage. I wouldn’t be able to make iDisk backups of my databases, and there are many users with databases larger than mine.
After all, how much trouble would it be to simply drag the backup archive to your iDisk? Just drag the archive into the Documents folder in iDisk.
But if you want to make iDisk the location for archived backups, you can always ‘hardwire’ the script to do that. Should be a simple exercise. Then you can post the modified script on the forum for other users.
WhileI voted “yes” I’d really prefer peer-to-peer syncing or a server other than .Mac.
On the .Mac syncing front, it’s worth pointing out that you can work around the ‘.mac’ requirement by creating your own webdav server.
oreillynet.com/mac/blog/2006 … _serv.html
tnpi.biz/computing/mac/tips/idisk/
It requires some mucking with apache, but it’s definitely the route I’ll be taking if DtPro supports .mac synchronization. I’d say syncing is my #2 hassle with DT, #1 being keeping multiple databases open concurrently [ideally with one of a specified default for imports]. Can’t wait for 2.0!