Multiple libraries for multiple servers with different login credentials

crobar

Thanks for zotero, it's excellent, and some day I hope to have time to contribute to its development.

In the meantime, I have one feature request though, and that is multiple libraries, each with their own syncing location and login credentials. This way my inststitution or company can have their own WebDav server (or even zotero server), which appears as its own library, and I can continue to use my private zotero account, and see it all in one place. I'm imagining a situation akin to having multiple separate email accounts in Thunderbird or Outlook.

So far I'm just using the standalone client, and am very new, so apologies if I've missed the possibility of doing this already. I did have a search and didn't see quite the same request as this elsewhere, so sorry if I've overlooked this too.

mronkko

I believe that you can achieve this kind of setup with group libraries already.

crobar

As far as I can tell (and I could be wrong), the group libraries can only be used with the central zotero server, I don't see a way to point each group library to a different server, at least not from the instuctions here:

http://www.zotero.org/support/groups

or from looking in the preferences in the client, but admittedly I haven't actually set up a group yet to try it out.

mronkko

Why would you want to have a different server for each library? What do you want to accomplish with that kind of setup, maybe there is already a supported way of doing that?

crobar

Well, just as I suggested, my company or institution could then host it's own private secure zotero server, to share stuff they are not wiling to trust to a third party, and I could work with each account seperately, and still have my own zotero account, all accessible from the same client.

Pretty much for the same reasons companies and institutions have their own seperate email servers etc really.

mronkko

Why not then just put all your accounts to the institution server?

crobar

Ok, but what happens when I leave the institution/company?

I also might have things I don't want to share with them either. As an example in my actual situation, I work for a university, but do consultancy work for multiple companies. Each of these would in my workflow have their own mutually incompatible server.

mronkko

You can just then switch to another server and do "restore to server". If you really do not want your institution to get access to your data, you can use another firefox profile and not synhcronize that.

crobar

Yes, that is certainly an option, but the feature request is really to automate and streamline this process (or equivalent, but acually designd for this purpose process) for the user, so it is a feature, and not just a sort of complicated hack of existing features to get the same functionality.

Sorry if that sounds like I'm disparaging the zotero software, I'm not, it's really good, but the essance of my feature request is to streamline the process you described for the user.

mronkko

I doubt that that is a very common use case, a good workaround exists, and also what you are requesting would be quite an architectural change. I doubt that the developers will implement this because of the effort required and the probably quite limited usefulness of this request.

crobar

Are you a dev?

If so, I suppose I'll just have to look to implementing it myself if you do speak for them. However I also think the idea of having multiple mutually exclusing accounts in a piece of software like this is a pretty common use case.

mronkko2

I have contributed patches, but I am not Zotero employee.

Zotero accepts third party patches, but you should email your plans to zotero-dev mailing list to get feedback before you start implementing this. It is easily weeks of coding and testing.

crobar

I probably will do this, but since I know C++ and Qt, but have never worked with firefox plugins or javascript or java, it might actualy be easier to develop my own client that interacts with any zotero API hosting URL you point it to.

I'm guessing sticking together libcurl for the backend and some GPL email client for the GUI would get you halfway there. I find it surprising that it would be such a huge architectural change to allow multiple accounts with different base urls in the existing client, but then, I haven't looked at the code yet.

adamsmith

I think you're underestimating (massively) the complexity of syncing. This is about _way_ more than a base URL. There are discussions of running your own Zotero server together with a patched client on the dev listserv, including links to such patched versions and an easier to deploy version of the server code, but it takes a pretty serious commitment to keep this up and running (though I know of several groups that do)
https://groups.google.com/forum/?fromgroups=#!topic/zotero-dev/p5Mlvnw3nXY

crobar

I am sure underestimating the difficulty, although the patch to the client to use a local/alternative dataserver looks pretty tiny. The addition of two configuration variables. Based on that I don't see how you couldn't quite easliy have multiple configurations in the client, unless there are many other configuration files I don't know about. I'm guessing you have to change some of the other variables in this configuration too, but it looks like the hard work is in the server setup side, which would be handled by my imaginary corporate IT team in my hypothetical company.

crobar

Oh, and thanks for the information/links by the way.

mronkko

The patch to use local server is small. The difficulty is supporting multiple servers. To start with, you have no guarantees on uniqueness of key-library combinations, or user ids, or group ids across servers. To solve this, you would need to change the data model so that server id is added to all primary keys. This would lead to redoing foreign keys and indices in the database, and also modifying a large number of Zotero funtions. Then you would need to figure out to how to handle item relations across servers. These are just a few of the things that you need to consider in the data layer of the App. Some other complications would arise in the word processor plugin, where you would have to take the server id into consideration as well. This would most likely make your documents incompatible with anyone else's.

Rolling out your own client with full Zotero functionality would be years of work. I have coded an iPad client, and even the currently limited functionality, it has been months of work.

But if you want to pursue either of these options, I recommend first documenting the design that you plan to have and then emailing it to Zotero dev mailinglist for feedback.

https://groups.google.com/forum/#!forum/zotero-dev

crobar

Ok, this does sound quite involved, but why not just have a separate local database associated with each remote server location/config? I don't see that it requires any server-side modifications, or modifications to the structure of local databases. It just requires the client to have a separate copy of everything associated with one server for each server, and a separate config for each surely? The servers in my model are separate, and not to interact with each other in any way (no copying docs between them except by adding manually for example).

crobar

This is probably better discussed on the dev list like you suggest though.

mronkko

Yes, this belongs to the dev list. You should first "do your homework" by studying the code and design of Zotero and to think what kind of problems you are likely to face. The dual database setup does not remove the problem that you would need to hack a large number of Zotero functions (and some of the data model) to have a new variable that indicates which DB to use. If you just one to use one database
and have "no interaction" between the database, then you could just use two different firefox profiles (and e.g this extension https://addons.mozilla.org/en-us/firefox/addon/profileswitcher/)

crobar

Yes, I'll certainly get a better grip on the issues you point out before bothering the dev list.

Thanks for all your input on this.