search

jimmejardine / qiqqa-open-source

The open-sourced version of the award-winning Qiqqa research management tool for Windows
GNU General Public License v3.0
374 stars 61 forks source link

BUG: Change the way libraries are handled (to suit a opensource product) #267

Closed raindropsfromsky closed 3 years ago

raindropsfromsky commented 3 years ago

At launch, the free version of Qiqqa does not make us log in at the website, meaning that there are no paid accounts (as expected).

So,

  1. Unlike the paid version of Qiqqa, the opensource version of Qiqqa should launch a library that is named after the Windows User Account.
  2. Let the user change the name at any point of time, because he may want to create more than one libraries.
  3. A multiuser computer will have a separate library for each user.
  4. On a given computer, this library should not be common amongst all Windows Users, and should not be named "Guest" library.
  5. Each user should be able to create any number of libraries, and name them as he wants.
    Typical use of this feature is to have a different library for each subject.
    The advantage of this approach is that the autotags and themes for each library are created based on their own documents, and not created on a mixed collection.
GerHobbelt commented 3 years ago

Very swift reply/notes on this:

2: intend to code this. Not there yet (need to add UI). See commit 3fadd9c651296d57fb98a65bdd8001be9470e568 message for related work: done a few days ago and it's me doing away with the various library types from the commercial era. Note the TODOs listed in that commit msg.

  1. sound good, but 3 (and thus 1+3) means I have to change Qiqqa so it checks which user is currently logged in on the local box. There are Win32 APIs for that one, so no problem, but I'd rather keep Qiqqa user-agnostic (my previous experience with applications that offer 1+3 isn't good (old Autodesk products come to mind, MS Office in "flexible workplaces". 🤦 ) and it'll open a can of feature requests about access control next that I'd rather not spend time on: multi-user machines where Qiqqa should manage/restrict access to their libraries. I'd rather leave that to the plant administrators who get a hard-on for this sort of thing as it has a very "corporate entity" smell to it 😉 and I wonder how many folks are sharing their machine that way, for real. (In my experience, the 'flexible desk' concept (no fixed work spot for employees) is the prime example needing this feature and all the places I've worked with that 'policy' had one thing in common: it doesn't work (except in the financial modeling spreadsheets of some consultant and CFO) and everybody is upset about all IT stuff.

  2. Given my aversion to 3, may I suggest calling the initial (and always present) library "Base" instead of "Guest"? (which indeed is ludicrous now that we don't have qiqqa logins any more) -- think "one person, one machine".

  3. Yup. Is already available as a feature, I think. (That is: when I 'forget' 3 as Qiqqa is user agnostic that way and it doesn't care who's logged in on the local machine, if you have installed qiqqa (i.e. you can run qiqqa on your local machine), then you've got access to the libs (base directory is set up in global registry key so qiqqa knows where to look for the libs)

Of course that can be changed, but there's another argument why I'm against 3: most users are running "one man, one machine" setups (or "one man, multiple machines" 😄 ) and when something goes bonkers, one thing you can do in Windows is start it in safe mode. Whoops. different user access there, you won't be able to reach your qiqqa libs and next thing you know I'm knee deep in Windows ACL (Access Control List) support calls -- that's my nightmare there.

5 is indeed a good policy and qiqqa COULD DO better there (you probably haven't noticed yet, but I did): currently qiqqa keeps PDF copies PER LIBRARY, while OCR text extract cache is shared across libraries. I've been thinking about adapting Qiqqa to have a 'global' PDF cache, i.e. not per library but per machine and that would mean you don't have multiple copies of the same PDF loading your disk because you have the same PDF in multiple libraries. Document copying across libraries would then become only metadata copy/clone in database, fingerprint hash for PDF is key anyway, so copying the metadata to the other lib should then suffice to have the PDF accessible there as well. (Less disk storage costs and there won't be any duplicate PDFs anymore in all the libXYZ/documents/HH/... directory trees.

Suggested initial lib name is "Base" instead of user name, because user name may be changed and I would like to have it transferable like that.

Argument against "Base" is that Sharing libs (sync Points) is on lib name basis; but then again this implies I'd assume the username is pretty unique which is a very bad assumption to make, so on second thought better to stick with "Base" (or some such) for everyone, so things are consistent across the populace, so to speak.

My 2 cents, straight off the top of mind.

raindropsfromsky commented 3 years ago

Ok you have convinced me.

In any case, the laptops are not so expensive any longer, and so the "one person one laptop" situation is a reality now. (For those who really cannot afford an i5/i7, there are budget laptops.)

Also, even if several users are sharing a laptop, they may have privacy concerns about financial data (such as spreadsheets), but a knowledge discovery tool like Qiqqa may not be that sensitive. In its role as citation manager, its sensitivity may be even less. And finally, if the user is so sensitive about privacy, he may as well get a separate laptop.

I like the idea of changing the name of the default library from "guest" to "base". But this is a minor detail.

So with these considerations settled, and out of the way, this issue reduces to #268. So I am closing this issue.

(I am adding my notes here, so that other users who have these needs can evaluate the logic and reopen this issue if they want)