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

No-SQL in mondo's case is an option, but its performance is less documented than SQL is in general, and has performance pitfalls where SQL shines, and vice versa. Let's just agree there's pros and cons for Mondo that we don't need to go into citations.

Instead, let's look at practicality - The tech is old enough, but not mainstream enough to be of use - it's like asking Adobe to write software for OS2. OS2 was amazing, but not supported, never took off and though it's got a following still, it's not practical. Neither would coding for WebOS - much better than Mozilla`s offering, but, well, it's HP's debacle. *sigh*

Asking Adobe to flip from Mac OS UNIX into Linux would be more in an applicable path. Thereby opening up that whole realm of revenue. SO tweaking SQLite into SQL full is not as big a move as rewritting everything into Mondo.

Thing is, Mondo throws another wrench in the works that is unnecessary. No one knows it.

As for Adobe not "anticipating" the need for a proper SQL I don't believe is the issue - there's no way all those nerds were sitting in the development meetings thinking they could write less. It's a decision likely taken by the shareholders and management to write a cheap goto solution for a niche and see what happens.

We now know what's happened - awesome potential, crap foundation - so Adobe shot itself in the foot going with an open source engine. Plain and simple. Mondo is the same kettle of fish.

I love open source - but i don't RELY on it, because one day, it can just "stop". Sure a company can go bankrupt, but with licensing in place, it provides more stability than by donation only.

Because your bought the flickr model up.

LR probably isn't the best solution for you if you are dealing with such quick turnarounds when travelling. Sure, it may be worth while having a LR catalog based system in the office, but on-shoot.. Photo Mechanic? It's far quicker and easy to deal with when using it on a shoot

Again, it is irrelevant. But for your knowledge, I never delete a file unless I know it is already present on two physical drives.

How is that relevant! I am just saying that spinning disks are not avoidable, if you have terabytes of data to store. You were saying that it is not a valid option to store images on spinning disks. I am asking why? Your assertion makes absolutely no sense and does not contribute at all to the discussion...

Do you keep your images on CF card after a shoot, or do you delete them the second they are on the computer?

ie, a data centre with PB's and PB's of data capability. Archive, it's a normal way to do things when you have material that is needed but not wanted live. The flickr model is having everything live to everybody all at the same time, that's what they sell, so they have to put in the back end to deliver it - I doubt you need that

In production, you don't need that visibility. You offline what you don't need to LTO, nearline spinning disk or whatever, you then deal with the present.

It does use SQL lite, so the database is code is already SQL "oriented". Have you ever coded enterprise systems using mainstream SQL servers? Maybe you have, then in that case I don't understand your concerns. This is so basic stuff. Anyways, do you have the sources? Can you really say it would be a problem to move to another SQL implementation?

SQL databases are very very very (did I say very?) mainstream, it would just make sense to move towards a more robust option for database management system than SQL lite. If it is not SQL, I really don't care as long as I get more robust features for sharing and replication (let's call it like that so it is not confused with low level backups).

I have a feeling (I don't really know) that the LR developers did not anticipate the popularity of their software and maybe the decision to use SQL lite just needs to be revisited. This is part of the development cycle and I wouldn't be surprised that some people at Adobe are already considering it.

Have you got Flickr's budget?

SQL isn't the way forward in my opinion, re-coding would just be making best of a bad job. Changing DB's would be a far more valid use of time, but as you know, that won't happen.

I can write you a schema that will give LR catalogs full shared storage capability, they will be saved in the mongo DB and pushed to users. Check in and check out.