On Wed, Feb 3, 2021 at 3:07 PM Tobias Vogel <[email protected]> wrote:
> Hi Matej, > > thanks for your detailed reply and my appologies for not being more clear > about my use case! > Hi Tobias, > > The extension will let the user compile a list of remote hosts that i > currently store in a SQlite DB. Now the location of the ".db"-file is what > I need to store somewhere on the Server side. > I assume this "list of remote hosts" is not the same list of hosts on which you use cockpit. When you need to store some database on the server just pick a well defined location and use that. (like /usr/share/myapp/database.db) > > Has the cockpit API maybe an easy way to retrieve the directory where an > extension lives in? > I am not aware of it, but it would not be hard to write a simple function to find from where the extension is being served. But I would argue for not using that for storing any arbitrary data mainly as users may remove/reinstall your extension and the data would go with it. Also cockpit has a hierarchy of locations so it may happen that you would start using another location thus the data would not be found. MM > > Alternatively I thought about storing the database elsewhere (like a > MySQL-, Postgres- or other relational DB) - however, this would require the > ability to enter the db connection-details and again store them somewhere > on the Server side. > > Regards, > > Tobias Vogel > > Am 3. Feb. 2021, um 07:28, Matej Marusak <[email protected]> schrieb: >> >> Hey Tobias, >> >> You haven't said exactly what it is that you are trying to store. For >> different data, there are different approaches. I can think of a couple of >> different cases: >> >> 1. I'll start with stating the main idea behind cockpit - it is just UI >> around other tooling, so ideally that other tooling would deal with it and >> cockpit would just read/manage it. Such example is for example how we would >> "store" user preferences for kernel dumps. We read the current settings >> from /etc/kdump.conf and show that on the page. When a user selects >> different options, we just tell kdump what the user wants and it updates >> this config (or we might edit that config directly, not sure now). Cockpit >> in this case is really just an intermediator. >> >> 2. You want to store something about how the user uses the UI itself. >> This is for example how you would select the language or color of >> 'Terminal'. This is saved in Cookies (for example look for `theme_cookie` >> in the source code to see how it is being used). There are other browser >> storages available that you can use. They all differ for how long the >> settings are saved. What they have in common though is that they all are >> only for you current browser and if you connect to the same machine from >> somewhere else or with a different browser, you will lose these settings. >> >> 3. There are cockpit configuration files. These are not really what you >> want for your extension, so moving swiftly on, but you can read about it in >> [1] >> >> 4. If you still haven't found what you need you are left to designing >> your own storage. The same way how you would create some config for your >> command line tool, you can create such config for your cockpit extension. >> About where on the system the file should be located is very dependent on >> what you are trying to achieve and SO can always be helpful with that :) [2] >> >> Hope this was to some use. >> >> Happy Hacking, >> MM >> >> [1] https://cockpit-project.org/guide/latest/cockpit.conf.5.html >> [2] >> https://stackoverflow.com/questions/47819464/where-to-save-configuration-data-files-on-gnu-linux >> >> >> >> On Tue, Feb 2, 2021 at 7:38 PM Tobias Vogel <[email protected]> >> wrote: >> >>> >>> Hi, >>> >>> I am working on a Cockpit-extension and was wondering what the >>> proper/preferred way is to store data from the user (variables, >>> preferences, etc.)? >>> I couldn't find any information regarding this in the documentation. >>> >>> Regards, >>> >>> Tobias Vogel >>> _______________________________________________ >>> cockpit-devel mailing list -- [email protected] >>> To unsubscribe send an email to >>> [email protected] >>> Fedora Code of Conduct: >>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/ >>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines >>> List Archives: >>> https://lists.fedorahosted.org/archives/list/[email protected] >>> >> >> _______________________________________________ > cockpit-devel mailing list -- [email protected] > To unsubscribe send an email to [email protected] > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedorahosted.org/archives/list/[email protected] > -- Matej Marušák Senior Software Engineer Red Hat <https://www.redhat.com> <https://red.ht/sig>
_______________________________________________ cockpit-devel mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/[email protected]
