Registry backend design

Projects STF 2022
25

The current agenda is:

  1. Final Review of the database schema and APIs.
  2. Discussion regarding frontend framework (I would like to consider node.js/react, Flutter, flask render template).
  3. Considering Keeping Mongodb as a Stateful container on AWS or using the MongoDB Atlas. ( the former is slightly costly and difficult to manage and second option is cheap but would cause some latency.)

CC @awvwgk @minhdao @certik @milancurcic @everythingfunctional @gnikit @ivanpribec @zoziha @arteevraina

2 Likes
26

I have Hosted all the User CRUD APIs (login, logout, signup, forgot password, reset password , uuid and cookie based auth , password hashing) and search package, upload package , user main home page here : https://henilp105.vercel.app/ , Please feel free to do testing and I would like to request all the Community members to review and add suggestions on this User CRUD APIs PR #3 . Please feel free to add suggestions/reviews. This frontend is a template and would request to use CURL to ping the APIs.

Thanks and Regards,
Henil

CC @awvwgk @milancurcic @minhdao @certik @everythingfunctional @FedericoPerini @gnikit @arteevraina @ivanpribec @zoziha

1 Like
27

I think ~/.local/share/fpm would be more appropriate than ~/.local/fpm, but it is certainly debatable. The same location on MSWindows or %APPDATA%\local ?

1 Like
28

Thanks, will be in ~/.local/share/fpm now. The equivalent on Windows (%APPDATA%\local\share\fpm, I believe). Does the latter make any sense? :thinking:

29

We need an MSWindows guru to weigh in. I only use MSWindows to set up a few things for others. WIth what experience I do have I would personally put it in %APPDATA%\Roaming\Apps\fpm\ , but I defer to any MSWindows guru who would weigh in. The \Local directory is used if you do not want the data
to follow you from device to device, the \Roaming directory contents can automatically follow you from device to device; not at all sure yet which would be appropriate for this file so \Local might be what you want, but that is basically the difference between the two. Would this be something you would want the same for a user no matter where they are running or would it have information in it that should be set on each device? I am assuming the file does not have conditionals in it that let you specify what it should do based on system type, which makes \Local a safer location. Sometimes you can look for both, first in \Roaming, and then override with anything in \Local. That is what I generally do when most of the settings are global but you might have something that is device-specific.

Any MSWindows people that have experience setting up applications want to weigh in?

1 Like
30

Yes, I think there will be good reasons for storing the config file in either %APPDATA%\Local or %APPDATA%\Roaming but it seems that the latter is no longer supported on Windows 11 (search for ā€œRoaming dataā€ in Store and retrieve settings and other app data - Windows apps | Microsoft Learn). And as Iā€™m currently not keen on setting up Azure App Services, I think %APPDATA%\Local\fpm\config.toml is the easier and more maintainable solution for now.

1 Like
31

Nice catch. Looks like Roaming\ is out then. Per the reference you sited there is now a much more formal format for the files with a pre-defined API for using them as well; I have placed custom-formatted files there as being proposed for fpm without issue in the past. I am looking for any documentation that indicates all files there are assumed to use that format, which appears similiar to but perhaps not identical to the fpm config data format; unlikely it is a problem but worth looking around a bit.

32

We have been working to enhance the metrics we monitor for each package. Hereā€™s a list of metrics weā€™re currently considering:

  1. Download Count:

    • Number of times the package has been downloaded.
    • Download trends over time (daily, weekly, monthly) and across various versions and clients (linux,windows,mac, registry website) (similar to crates.io)

  2. User Feedback:

    • Ratings and reviews from users. (we are also working on the package deletion rules)

  3. Security Metrics and Notifications:

    • Identification of vulnerabilities and security issues. (these notifications will be added on both the registry frontend and fpm cli)

  4. Usage Geography:

    • Geographical distribution of package downloads on the package page.

Weā€™re eager to have your feedback on:

  • Are there additional metrics you believe are crucial for the Registry ?
  • Which of the listed metrics are most important to you as a Fortran developer or user ?

We will soon be also releasing a new version of both the registry and the fpm for another round of testing and feedback.

Thanks and Regards,
Henil

CC: @awvwgk @certik @arteevraina

4 Likes
33

I am curious why are we collecting 4. and especially 5.?
In general, we need to be transparent as to why we collect data, how we store them and who has access to them. How does anonymised data or geo usage data improve Fortran-langā€™s tools, or the organisation as a whole? I personally donā€™t see a strong link between the two.

EDIT: I see point 5. has been removed from the original post which is fair. The arguments about data collection, however are still valid IMO.

3 Likes
34

@gnikit We had intended this for Optimising purposes like for setting CDNs or Mirrors and this data could also be used for usage pattern analysis/monitoring.

we would prioritize user privacy and anonymize the data and clearly communicate data collection practices in accordance with GDPR.