Add location for storing citation styles

[k3KAW8Pnf7mkmdSMPHz27]

We need to store the citation styles somewhere, the main options are

1. Store them inside of the word addin (probably not a good idea)
2. Upload them at the same time we deploy the plugin, but then we need to know the URL we are deploying to
3. Create static storage or an API where we can query for the citation styles
   4. can we do this with our current Azure setup?

We need to store both the citation styles themselves (https://github.com/citation-style-language/styles) and locales (https://github.com/citation-style-language/locales)

[tobiasdiez]

Store them inside of the word addin (probably not a good idea)

I like this. Why do you think its probably not a good idea? One could treat these files simply as static assets (i.e. similar to small images) and simply copy them during build.

Create static storage or an API where we can query for the citation styles

That's an option too, probably using Azure storage. But the Azure static website we are currently using is essentially also an Azure storage instance with bells and whistles so there is not much advantage of using it. I guess the main advantage would be that the styles can be updated independently of a build and that the build times are minimally lower.

[k3KAW8Pnf7mkmdSMPHz27]

I like this. Why do you think its probably not a good idea? One could treat these files simply as static assets (i.e. similar to small images) and simply copy them during build.

I guess my first concern would be the size of the plugin. But perhaps an extra 36 MB isn't too bad, or 11 MB if we keep them zipped. Secondly, we'd need to build some sort of index during the build step but perhaps a sorted list and binary search would be enough and not too expensive. I don't know a whole lot about the styles files but the title and title-short,

    <title>ACM SIGCHI Proceedings - Extended Abstract Format</title>
    <title-short>CHI Extended Abstract Format</title-short>

seems sufficient to search on.

That's an option too, probably using Azure storage.

Something that allows us to search for files rather than just file names would be the most important part. We were discussing some server that could be queried but perhaps it is overkill.

I guess the main advantage would be that the styles can be updated independently of a build

Yup, and add-in size.
Afaik there are no size limits on the Office add-in as such so perhaps I am putting too big an emphasis on it.
There are RAM/CPU limits but I don't think this functionality will hit either for any device we'd try to support.

[tobiasdiez]

What do you think about the following:

• Add the citation styles as a git submodule somewhere, let's say assets/cls (maybe it's better to put them somewhere else and copy them as part of the build process depending on how much auxiliary files to pull-in as a submodule; but let's ignore this)
• Initially, and every time the submodule is updated, create a javascript index file that contains the necessary info about each style (say filename + title + description). That's similar to https://github.com/JabRef/jabref/blob/7ec4c7e89524e406de1277c1cf58513bf8c1dc1c/src/main/java/org/jabref/logic/citationstyle/CitationStyle.java#L60-L79
• During deployment, the cls files are deployed as static files to /assets/cls (e.g. /assets/cls/aci-materials-journal.csl) and the index file is processed as a normal js file (i.e. included + mimized). In principle, we can also rely on github by downloading from https://raw.githubusercontent.com/citation-style-language/styles/master/academy-of-management-review.csl but that might turn out to be problematic in case the styles are renamed upstream.
• The plugin mostly uses the information contained in the index file (e.g. for the ui).
• The only exception is when the citation string is produced, for which the actual style is downloaded from say /assets/cls/aci-materials-journal.csl. (This needs caching, maybe even somewhat intelligently after the user selected a new style.)

In this way, the user only downloads the styles that he really needs.

There is of course room for optimization. For example, one probably doesn't need the whole index file but only parts of it. This then indeed would require a proper server + endpoint; but I would say let's worry about this later.

I agree, if one doesn't want to build the index beforehand, then a server implementation (or file storage + search) is necessary. But as the index is essentially static and only need to be rebuilt when the styles are updated, I don't think this is a huge overhead.

[k3KAW8Pnf7mkmdSMPHz27]

I think we are mostly on the same page 😛

I.e., there is a lowest hanging fruit that is,

1. copy-paste the style files
2. generate an index matching (description) title -> filename

But except for that, I think I need to do a bit more Googling X)

Initially, and every time the submodule is updated, create a javascript index file that contains the necessary info about each style (say filename + title + description)

Agreed. Not sure how to deal with submodules -> me googling.

This needs caching, maybe even somewhat intelligently after the user selected a new style

I've assumed files in assets can be accessed without network access and that this would be the easiest/simplest way of dealing with them in that case. I'll have to look into it.

In this way, the user only downloads the styles that he really needs.

Perhaps that does end up being the easiest way, even if some caching solution has to be used. Why would you need a cache instead of viewing it as lazy loading a resource and therefore automatically storing all the accessed styles for the session?

[tobiasdiez]

I've assumed files in assets can be accessed without network access and that this would be the easiest/simplest way of dealing with them in that case. I'll have to look into it.

The add-in is essentially only a website that we have to host ourselves and which is essentially side-loaded in a new frame. This means that there is not such a thing as "offline access".

Why would you need a cache instead of viewing it as lazy loading a resource and therefore automatically storing all the accessed styles for the session?

Good question. Maybe it's already sufficient to let the browser handle the caching. What I wanted to prevent is that every call to the csl library triggers a re-download of the style file.

[Siedlerchr]

We could use local storage https://docs.microsoft.com/en-us/office/dev/add-ins/develop/persisting-add-in-state-and-settings