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

"What we are asking for on this forum is a pretty hefty amount of programming."

If Adobe would use current proven technologies to accomplish that and not re-invent the wheel, that would not be that big of an effort. Sure, it will take time and engineering but it's not like we are asking to build something that does not exist. There are environments with much much more complex concurrency problems at a much bigger scale today. The tools and patterns are already there and waiting to be used.

"Does it mean that we shouldn't be asking for this feature? No. It's a really really needed thing, much more than better retouch tools or some nifty little button or other. "

Cannot agree more. 🙂 At least we can talk about it, maybe dream a little, no harm in that.

Walter, thanks for the clarifications on Bridge's potential integration with a DAM server, I was not aware of that. Something I will look into.

"LR does as well. Sidecars and some embedded xmp. Not all by any means. (All of this is limited by the FS IO speed.)"

yes an no, the metadata is stored in the catalog and LR does not scan the XMP files when searching in the Library module. It will only pull it if the user refreshes the metadata manually. It uses it's SQL lite relational database. Bridge (when not connected to a DAM server at least) has to scan XMP files to build a metadata cache to allow searching. My point was that a proper SQL server would speed things up compared to SQL lite and certainly compared to scanning tons of little files on the file system (and worst on network storage for archives). Database servers are optimized to do that kind of thing with high performance caching, memory management and storage management to overcome the FS limitations while digging in relational data.

agreed. PS and LR are different beasts. PS is an optional step in the LR workflow but not needed all the time. LR speeds up things considerably and I want to keep using it for that reason

We essentially agree. Our backgrounds and needs are different but we are saying the same thing...

I like LR because it helps me avoid to use a bazooka when 60% of the time I only need a fly slapper. I could use the Bridge + CR combination but the LR GUI alone is enough to make me want to us LR.

But when I need to do heavy lifting, pixel based editing is needed.

You are suggesting to beaf up LR to also handle the other asset types and this can be a solution. The only thing is LR is really built with photographers in mind and that would mean to risk loosing the photographer focus. Maybe not. I haven't carefully thought about this option.

In any case, yes, Adobe needs asset management...

I don't think it's a win or loose scenario, you buy their products to create and make money and with forums and idea rooms like this, those ideas can be sent over to developers and the guys who hold the purse - If they don;t impliment what you want, you jump ship.

The period when Apple bought out FCPX, Avid and Premier were biting at the bit to get users on board with new features and price cuts

However, Avid have used proprietary storage for years and only recently have 3rd party manufacturers been able to 'get hold' of the file system goodness.

This is something i envisage Adobe trying their hand at, and so building adobe file storage based on Adobe drive and therefore making a file system that just works with adobe products. No, i'm not talking about psd's or stuff like that, but using it like Avid have used ISIS. You want to use our products, you use our file system. In a similar way they have gone down the 'apple app store' route with their products, cutting resellers and everybody else out of the chain.

Adobe only wins if we continue buying version after version without the tools being added. If you want to win at a business game, you have to speak with your checkbook. If software upgrades don't include the core components they should then don't buy them until such time that the programmer realizes that the sales have stopped or considerably slowed because of the lack of implementation. As many have said; doing the same thing over and over again but expecting a different outcome is insanity.

i don't know you and I completely approve of your message. 🙂

Hiya Mark,
I've actually found some informative stuff through this thread - you should tuck in with a hot coca and have a read lol
There are a few valid work arounds, that of course are beside the point but useful nonetheless.

I shall remain on the thread though as i have this soap box here, and it does require use *smiles*

Beside, if we give up... the Adobe wins.

-->Bridge's sharing capabilities rely solely on sharing capabilities of the network and file system. Hardly a good solution for concurrent updates and performance.--

Not so. Since something like the second version of Bridge, premium customers have been able to implement a DAM server for bridge to check in and out files. Now it's called something like Adobe Drive. I used it back in the day.

What did this nifty software use for keeping everything version controlled and checked in and out? Yep. MYSQL.

---I say performance because bridge needs to scan files to grab the metadata. ---

LR does as well. Sidecars and some embedded xmp. Not all by any means. (All of this is limited by the FS IO speed.)

---It caches the information but cannot compete with proper SQL engines ---

see above statement. Locally, no, it can't.

---for searches on a large volume of data. Concurrent updates because files systems do not have built-in support for concurrent updates,---

sadly ZFS was killed in OS X. There are many concurrent-use algorithms and even file systems that can do this. Implementing a virtual file system sandbox would mess things up and slow things down though . . .

---whereas SQL servers are pretty good at it...

Agreed, storage technologies have nothing to do with the topic...---

Storage tech has everything to do with it. It's the reason why Adobe has not been able to implement good multi-user with almost any of their software. Too many different file systems and networking share protocols. It make it very hard to create a client-only type sharing situation (think iTunes) with multi-gigabyte sets of images and more than 100 concurrent transactions per second. But many applications already do this. It's not impossible.

Probably a client/server architecture is needed like Adobe Bridge, Indesign, and a slew of other Adobe products in use today.

A good primer on anyone on this list wanting to understand concurrent editing tech should read this:

http://www.waveprotocol.org/whitepape...

and this

http://en.wikipedia.org/wiki/Operatio...

Maybe some of the rants will simmer down a bit and people can start thinking critically.

--------------

What we are asking for on this forum is a pretty hefty amount of programing. Right now I can select and batch edit 100,000 images in one swipe on LR. Enabling something like this in a 50 person multi-user environment like the NY Times could be totally bonkers. There are some major and complex details to work out if concurrent or multi-user was implemented especially in a non checkin/checkout situation.

Does it mean that we shouldn't be asking for this feature? No. It's a really really needed thing, much more than better retouch tools or some nifty little button or other.

Best,
Walker Blackwell
--
Black Point Editions, Founder
Latitude, Co-Founder