[JMP14] Project archive paths -- request for review and comments.We are trying to modify and improve the path system of files in a project when those projects are archived and shared with others that avoid the previous issue of very long nested paths like: C/Users/davle/documents/current_work/2016/blah/blah/blah/file.jmp which result in a nest folder structure when the project is unarchived.
Journals have this issue, too, when they are shared and contain absolute paths to files. @brady_brady's journal packager helps with this to flatten path and make them local and many of use do this manually by editing the scripts. There is the potential for collisions as well, say, if a project has folderA/bigclass.jmp and folderB/bigclass.jmp. Those non-unique names might actually be different data tables.
At any rate, I am looking for some help reviewing our proposed solution. In seeing the below cases, does anyone see any issues with these filename conflict situations. And does any of this bother/confuse anyone?
Remember this is when I have project with a number of files bookmarked and then I go and try to archive this project, brining along all of the files, with the goal of sharing my project with someone else, who will consume it on their computer and not care/want to know where the original files are located on my file system.
Project Archive Paths
Original disk paths on the left; archive paths on the right
Scenario 1
C:\Program Files\JMP\Samples\Data\Big Class.jmp
|
|
|
|
|
C:\users\aander\Desktop\JMP\Big Class 3.jmp
|
|
//jmpsi.na.sas.com/users/aander/JMP/Data/Big Class 4.jmp
|
|
Scenario 2
C:\Program Files\JMP\Samples\Data\Big Class.jmp
|
|
|
|
|
C:\users\aander\Desktop\JMP\Big Class 3.jmp
|
|
//jmpsi.na.sas.com/users/aander/JMP/Data/Big Class 4.jmp
|
|
Scenario 3
C:\Program Files\JMP\Samples\Data\Big Class.jmp
|
|
|
|
|
C:\users\aander\Desktop\JMP\Big Class.jmp
|
|
//jmpsi.na.sas.com/users/aander/JMP/Data/Big Class 4.jmp
|
|
Scenario 4
C:\Program Files\JMP\Samples\Data\Big Class.jmp
|
|
|
|
|
C:\users\aander\Desktop\JMP\Big Class.jmp
|
|
//jmpsi.na.sas.com/users/aander/JMP/Data/Big Class.jmp
|
|
Scenario 5
C:\Program Files\JMP\Samples\Data\Big Class.jmp
|
|
|
|
|
C:\users\aander\Desktop\JMP\Big Class.jmp
|
|
//jmpsi.na.sas.com/users/aander/JMP/Data/Big Class.jmp
|
aander\JMP\Data\Big Class.jmp
|
 \Stuff\JMP\Data\Big Class.jmp
|
Stuff\JMP\Data\Big Class.jmp
|
Scenario 6
C:\Program Files\JMP\Samples\Data\Big Class.jmp
|
|
|
|
|
C:\Program Files\JMP\Samples\Aaron\Big Class.jmp
|
|
|
|
|
Re: [JMP14] Project archive paths -- request for review and comments.Re: [JMP14] Project archive paths -- request for review and comments.Hi Dan,
All of your solutions seem reasonable to me. I like the super short archive paths you show the best. Just a question though. Will you be able to hover over the archive name to see the original file path? I could see this being helpful when you have the non-unique file names where the files are actually different..
Bill
Re: [JMP14] Project archive paths -- request for review and comments.Hi Dan,
For a journal, I default to copying table scripts and inserting them as a script. It results in a robust journal that can be emailed without fear of broken table links or need to zip a folder of files to then email. Have you considered that option for projects? At least via preferences have the option to save a script for the table rather than a link, then we don't need to worry about broken links.
Best,
Malcolm
Re: [JMP14] Project archive paths -- request for review and comments.How much work would it be to offer the user a run-time choice at the time of "unarchiving" the project:
1) Use original folder names
2) Use shortest unique path
3) Use shortest unique folder
The user could decide; after all the choice isn't always clear... there are tradeoffs. Sometimes the FULL path (for example, when the project is shared only within an organization) would containing meaningful contextual information, that the users might be loathe to lose. In this case they could use option 1. Option 2, shortest unique path, might be appealing in most other cases, as long as the "good" / "bad" scenario Aaron describes isn't a problem. In that case, use option 3.
If only one way can be implemented, I am not sure which to choose. They all have pros and cons; to a given user, any one of the 3 options might be the overwhelmingly obvious choice. Maybe EAs will have some feedback on what is most useful to most people.
Re: [JMP14] Project archive paths -- request for review and comments.There is also a variation on shortest unique path, which I'm calling shortest unique folder. It's the same as before, except that we keep adding folder levels to ensure that files which originated in differnt folders don't end up in the same folder in the archive. That would change Scenario 6 above to look like this:
Scenario 6
C:\Program Files\JMP\Samples\Data\Big Class.jmp
|
Samples\Data\Big Class.jmp
|
|
|
|
C:\Program Files\JMP\Samples\Aaron\Big Class.jmp
|
|
|
|
|
We still have some oddly named folders (at least in the sense that it's not very clear, unless you know the details of the algoritm, why it puts things where it does), but it sovles the problem of putting things together that weren't meant to be together.
Re: [JMP14] Project archive paths -- request for review and comments.For context, what Dan posted above is the result of one algorithm we're calling shortest unique path. Essentially, if two files in a project have the same filename, we would store them each in a different folder using the name of the folder containing each file. If two or more files had the same filename and were in folders with the same name, we would save two levels of nested folder structure, and so on. This was an attempt at putting things in recongizable places without having to store entire folder structures. However, as shown in Scenario 5 things can get pretty confusing, and as shown in Scenario 6 we could actually result in files that originated in different folders being put together in the project archive.
What worries me about Scenario 6 is a project with the following paths bookmarked:
/data/broken data/2017-04-20/data.jmp
/data/correct data/2017-04-20/stuff.jmp
/test/data.jmp
/test/stuff.jmp
Under the shortest unique path algorithm, these would be copied into a project archive as:
/2017-04-20/data.jmp
/2017-04-20/stuff.jmp
/test/data.jmp
/test/stuff.jmp
Resulting in a 2017-04-20 the "broken" data and the "good" data being stored togheter. Which bothers me for some reason, even though technically everything stil works.
