On 8 sep 2010, at 01:26, [email protected] wrote:
> On 2010-09-07 04:23 , John Stalberg wrote: >> A per user solution together with more clear limitations on running the same >> files in parallell [...] might turn out to be a bit more doable than it >> perhaps seems to be at first glance. A concurent rate setting could be >> somehow stacked and executed first in first done. The major file changes >> could be made unavailable for the user when in parallell mode. > > i don't think you realize how much an engineer would shudder at the > fundamental changes that would require to the underlying model of an > application that was first released over a decade ago; > I realize such bloat as iTunes represents most probably is stacked like a play card house (don't know the correct english word but I mean the fragile tower one can build with ordinary poker playing cards by leaning two towards each other to make them standing and construct a buliding with this fundament) but what makes me brain storm regardless of this is I think I could come pretty close to a descent solution by scripting only. Not that I would like to do it, I have a solution already that is working fine for me. You have a point indeed, my point was to cast a light on the difference between a pure concurence problem you would find in a file system and this particular application. Not meaning it is easy. Just less difficult. // John Stalberg_______________________________________________ MacOSX-talk mailing list [email protected] http://www.omnigroup.com/mailman/listinfo/macosx-talk
