P: Allow Catalog to be stored on a networked drive.

exactly Andre - lightroom was to combat Aperture - and guess what they built on? SQLite - which by the by has NONE of the sharing issues - as SQLite was not designed to work on windows NTFS file systems correctly as that was proprietary MS tech they would have had to pay for - ie permissions -

Now that Lightroom is "mainstream" and as inundated on PC's as Mac's we have this issue. Imagine the storm that would ensue if Adobe "flipped" the sharing switch for the mac world like they could at any time....

as for your "self sharing" try freefilesync - I posted in your other thread why it may help.

Dude, you bought it up, just saying

stuartpeckphoto - I did not bring the flickr "model" up, I just used any large organization as an example that the only way to store significant amounts of data is still on spinning disks (or tapes for off-line backups). Thus your assertion is wrong. (you would be a successful politician). Obviously, the example is extreme as I do not have this kind of data to store. But the issues are the same, just at a smaller scale.

I could list you dozen of recent examples where I had to browse the 40k+ images I captured in last year. I want to use the cataloging features of LR to efficiently search images and 40k+ images do not fit on an SSD. What am I supposed to do, buy a bunch of CF cards? Distribute all my archive on many SSD? No, I have to use spinning drives since I want to see the whole thing once in a while (and more often than you seem to do yourself). I could also use another tool to search but that would 1) not fix the issue of storage and 2) force me to use another tool, where LR is fine for me.

The storage technology has nothing to do with the issue at hand. The point is around the asset management and sharing of catalogs. It would just be easier if LR allowed for easier sharing and syncing of "remote" catalogs WITH master files. I am not questioning the cataloging features, they are fine. Just this last part.

Performance is an issue (though not bad) but I would be happy with reduced performance on the road, with an off-line (SQL lite) based local copy of my catalog but then be able to "connect" to the master catalog when home or in the "office" and synchronize back, with a single function, from within LR, that would push back the changes in the master server AND take care of copying the master files to a central repository in the process. That is not a lot to ask with 2013 technologies. Just a matter of coding it with industry standard and proven tools.

Axiom - you may be right about the decision to go SQL lite being a management decision, most decisions are, in the end, in the software industry. But, it was also developed as a prototype, based on SQL lite and prototypes have a tendency to end up in the production line. I have seen so many proof-of-concepts being sold as is, that I have no issue imagining the same happening to LR. It then become very difficult, politically, to have funding to change the decisions down the road as the bottom line has a tendency to want to stay down and any refactoring involves hitting the ROI.

what kind of capabilities do you need other than it being a shared check in / check out scenario

stuart, fyi... a regular hard drive in normal conditions will far outlast your ssd's. That's just a fact. And even still, a 5 terabyte rack of 5x 1t 7200rpm drives are far cheaper to replace per terabyte then the same in ssd's.
I can live with a cumulative delay of 5 minutes by days' end, whilst saving the hundreds of bucks.

yeah, i'm talking about if you actually want to edit or export the original item. Think we're crossing Asset management, and DB management here

well actually, the data isn't "live" just because you're in an lcat...

If I'm in the library, all it's doing is referencing the preview cache - and same thing for Develop.
The only time lightroom pays attention to your "original" photo is pretty much when you click on it to MAKE the preview - it's not loading your images into ram and the processor and dimming the city's lights - it's just loading the database text.

So really, the only benefit to NOT using a normal hard drive is simply read write times - which if you have a dedicated on board drive - then there's no real performance hit other than a slight lag after a few flicks of the mouse wheel - the performance hit is in rendering and inital 1:1 previews which Capture One simply beats the snot out of lightroom for in performance. (apparently they can use GPU's for renders *sigh*)

So yeah SSD does add performance for read write, but your 50 million images are not "all loaded and live" until they are needed. o_0

HD's die, fact, no getting round that. But having them work more than they need to will certainly shorten their life span. So for data you don't need access to, archive off to either a nearline disk, which is raided. Or LTO. You have 3 recycled copies of those LTO tapes, which one lives in an underground bunker and two live on-site at your prod house. They get recycled at whatever frequency you are happy with.

LR is perfectly fine, it is great EXCEPT that it does not offer great capabilities for asset management.

I was suggesting that it's probably best not to store archive data on spinning disk. ie, Disks that are powered on and spinning. By all means keep them on HDD's but if they are archive, they don;t need to be live, right?