Hi thealanberman:
Your use-case example greatly aids my understanding about the way oDrive works… ahead of my playing with it to discover the same. The big design philosophy you opened my eyes to is that the oDrive “placeholder” object actually transcends that name… With a “normal” placeholder object (like a soft link back to a real object sitting on a Linux/Win cloud server/host) I don’t expect that anything I do with the object in my userland space is going to have any effect with the real object back in the cloud… particularly, I don’t anticipate that I have the ability to move the location of the real object within it’s real cloud/server directory tree space via my moving the placeholder object in my desktop environment directory tree space.
With oDrive enabling this kind of object movement-linking, it’s client-side desktop “placeholders” are really something more than placeholders. I’m not sure what to call these… I guess there are “mere desktop placeholder objects” and “oDrive Movement-Enhanced Desktop Cloud Placeholder Objects ™”… ha-ha!
In my idealization of “mere placeholders”, I don’t expect this ability to ever move real objects out on the cloud/server… At some common user level, the particular location of any cloud/server real object is an abstraction layer to me… I want my desktop placeholder object to isolate me from the real object directory tree location details out on the cloud/server. The oDrive Placeholder objects, in comparison, are providing me this additional strength to move the remote cloud/server real objects physically around out there in their real environment… but like El Joral (or some other comic-book Super Hero) once said - “With Strength… Comes Responsibility”, and likewise with this oDrive capability, now I’m forced to start paying attention to this cloud/server object directory tree location - that is, if I want my oDrive placeholder objects to continue working.
If I had the ability to move my desktop placeholder files around in my desktop directory tree structure willy-nilly (and even have multiple copies of the same placeholder object stored in multiple/different locations in my desktop environment), I can fluidly/quickly build a myriad of different desktop views onto my cloud storage. The way that oDrive works, it looks like I can build the same desktop myriad of views… but not too fluidly: at each desktop location that I want a new view, it can take a significant amount of processing for oDrive to build the new placeholder-objects back-linking to the real cloud objects… and then this desktop oDrive placeholder object is FIXED in one spot… if you want to move this object to a new location on your desktop directory tree, you essentially have to discard all that previous oDrive processing work and just start that onerous re-mapping process all over again.
Maybe these thoughts of mine are a bit too old-hat and I have to come around to accepting the cloud-era reality that objects on the server/backend might be subjected to being “moved around” (via oDrive but also the many “remote cloud mounts” popping up in new software everywhere today) as readily as objects in the desktop environment. I want the flexibility to move my desktop placeholders around my desktop environment willy-nilly… but… I have to admit that it’s actually more of a priority that they simply continue to work.
Hmmm… A new idea: How about instead of my initial thought to embed the cloud object mapping info into the desktop placeholder… we instead embed an index# value that references a mapping record line/entry in an oDrive locally maintained DB/list? Where a user conducts their desktop object and cloud object “movement activities” in the shadow of the oDrive oversight, these object location changes are duly recorded and immediately (or just soon/quickly) available for reference/inspection by placeholder objects. Would a change like this allow oDrive users the greater flexibility of moving desktop placeholder objects around willy-nilly (as I’m clamouring for) while also preserving oDrives present ability to enable users to move around cloud objects via their desktop regular OS file movement tools?
Even with this kind of enhancement, however, the scheme will also be subject to be broken where a user might use a tool to effect a cloud object move that the resident oDrive process doesn’t see and isn’t aware of. Maybe this challenge could be solved by providing a facility to have oDrive scan user-indicated important cloud storage areas (NOT the entire cloud environment!) looking for such surreptitious object movements?