Infrastructure » Extensions

copying remark from irc:

that is not really what you need for api within libreoffice - that is just getting detailed info for a single extension entry - so not really useful to present suggestions/results to the user.

Providing that info for a single extension in json or another parsable format is possible of course, but the important parts to fill a form from within LibreOffice is e.g. getting list of tags or searchterm or provide other filter criteria.
The current site already has a free-form-search along with a tag-filter, that later can be expanded by download-count and reviews (once the site has been in action for a while and had a chance to gather at least some amount of relevant numbers).
But especially reviews/comment count is tricky - as there is no incentive for users to rate an extension/you can only provide a rating after you downloaded and installed the extension. So you would have to go back to the extensionssite after having used the extension for a while to rate it.

Of course the scope of the extension discovery in LibreOffice can be extended to a call-to-action to rate installed extensions (but that needs to be tied to a configure switch that allows to disable this completely)

You are right. If I at least get the search result and download link of extensions with JSON or something else, this will be great for me. I tried writing a program to get data from the extension website. However, searching and getting links took a lot of time depending on the number of results.

from IRC:
12:56 <cloph_away> some quick remarks to your api if viewBy is meant to specify sort, just call it sortBy :-) as for the response: an extension can have multiple downloads assigned and multiple releases
12:56 <cloph_away> For api use I guess one can just return the latest release, but still it could contain multiple donloads.
12:57 <yusufketen> Yes you are right, download links may be an array with version numbers and download links.
12:57 <yusufketen> About viewBy, you are again right :) I will change with sortBy.
12:57 <cloph_away> also the foobarNumber should be called foobarCount
12:58 <yusufketen> What is the foobar?
12:59 <yusufketen> download and comment numbers?
13:00 <cloph_away> If I understand it right, you will always pass OS and version, so from silverstripe's controller point of view it would be more natural to have that as part of the URL domain/api-base/valueForOS/valueForVersion/optionalSorting[?q=...&page…&per_page]
13:00 <cloph_away> but that's optional, using all as query parameters is fine as well.
13:01 <yusufketen> I agree with you about the URL.
13:02 <yusufketen> That will be better.
13:03 <cloph_away> so the only real problems is how to deal with multiple releases/multiple downloads per release.
13:04 <cloph_away> most natural would be to change the download URL to a array on its own just like tags.
13:05 <yusufketen> I think we just display the latest release and latest uploaded download link
13:05 <yusufketen> Because the UI will be basic to easily download and install extensions
13:05 <cloph_away> But still it would be hard to distinguish releases then. So either you would do additional queries to get the release notes/description for the release, or you also want to get the release description (and the releasenotes) as part of the response.
13:06 <yusufketen> If people want to download and install other versions, they can go webpage,download and install via extension manager.
13:10 <cloph_away> https://extensions.libreoffice.org/en/extensions/show/ancientgreek for example has two variants, in this case they are using a different release version, but there are also some that use different variants (different language for the UI element for example) and use the same release/version label.
13:10 <cloph_away> So only way to differenciate betwem then is by looking at the description and/or the release notes.
13:11 <cloph_away> (also the API requst sould include LO's UI language like the other requests do, to be able to provide a translated response if the entries are translated/to prefer entries with translated entries over English ones)

I am aware that there is a problem with getting the latest release download link. So, is it possible to get the entire Release List(Version, name, description,license, and download link) with the API?

Also, I will send the system language as a parameter to API.

Thank you so much. I'm grateful for your efforts.

I added a new parameter to the API Document. (Tags) Also, I gave detailed explanations about the parameters and possible situations.

We significantly reduced our expectations about the API. Can you review the document? https://docs.google.com/document/d/1T89OPoI36rbX6Wy139Bd-N0Z9yc3xOm8KTjCb8Ch7Cg/edit?usp=sharing

Christian Lohmaier wrote:

https://extensions.libreoffice.org/api/v1/extensions/macOS/3.3?q=dictionary for example will return the extensions that are compatible with macOS and have a min-supported version of 3.3 and match the query string "dictionary" - I made os and version part of the URL since when running from LO those are always present.

This might lead to irritation when extension <foo_dictionary> is not tagged appropriately. Would be better to retrieve the extensions for a tag, whether via tag string or tag number.

as for the Tags api from your last comment - I guess we had a misunderstanding there - the tags API I mentioned was separate, and only give tags and extensioncount as described in the last comment, but not return the matching extensions along with that. To get extensions matching the tag, you do it as you'd do as a user with search and tag filters on the API, for example you would use

https://extensions.libreoffice.org/api/v1/extensions/?Tags[]=44 to get all extensions matching the tag with ID 44 (Writer) (can be combined with os/version and q/searchterm)

Heiko Tietze wrote:

Christian Lohmaier wrote:

https://extensions.libreoffice.org/api/v1/extensions/macOS/3.3?q=dictionary for example will return the extensions that are compatible with macOS and have a min-supported version of 3.3 and match the query string "dictionary" - I made os and version part of the URL since when running from LO those are always present.

This might lead to irritation when extension <foo_dictionary> is not tagged appropriately. Would be better to retrieve the extensions for a tag, whether via tag string or tag number.

That's for illustrative use only/what the API does/what the endpoint looks like, not for how to properly use the API from within LO :-) - I fully agree, to get dictionaries, you should use the dictionary tag as filter, and instead use your language's name as a query string.

Christian Lohmaier wrote:

https://extensions.libreoffice.org/api/v1/extensions/?Tags[]=44 to get all extensions...

Perfect

Can you check this JSON file? This completely works correctly. https://yusufketen.com/api/Impress.json

Because I couldn't validate the API JSON files from validation webpages like https://jsonformatter.curiousconcept.com/

As far as I see, there are HTML tags in JSON response which is come from the API. This is a problem for us.

Also, I'm not sure whether we delete non-ASCII characters(\u****) or not. I will ask this matter to my mentor.

Slipped through for a bit, should be done within the next days