How to store user-input data?

[Tobias Vogel]

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
⁣​

[Matej Marusak]

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-...



On Tue, Feb 2, 2021 at 7:38 PM Tobias Vogel <tobias.vogel(a)linux.com&gt; 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 -- cockpit-devel(a)lists.fedorahosted.org
>  To unsubscribe send an email to cockpit-devel-leave(a)lists.fedorahosted.org
>  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/[e-mail]...
>  

-- 

Matej Marušák

Senior Software Engineer

Red Hat

<https://www.redhat.com>
<https://red.ht/sig>

[Tobias Vogel]

Hi Matej,

thanks for your detailed reply and my appologies for not being more clear about my use
case!

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.

Has the cockpit API maybe an easy way to retrieve the directory where an extension lives
in?

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, 07:28, um 07:28, Matej Marusak <mmarusak(a)redhat.com&gt; 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-...
>
>
>
> On Tue, Feb 2, 2021 at 7:38 PM Tobias Vogel <tobias.vogel(a)linux.com&gt;
> 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 -- cockpit-devel(a)lists.fedorahosted.org
> > To unsubscribe send an email to
> cockpit-devel-leave(a)lists.fedorahosted.org
> > 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/[e-mail]...
> >
>
>
> -- 
>
> Matej Marušák
>
> Senior Software Engineer
>
> Red Hat
>
> <https://www.redhat.com>
> <https://red.ht/sig>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> cockpit-devel mailing list -- cockpit-devel(a)lists.fedorahosted.org
> To unsubscribe send an email to
> cockpit-devel-leave(a)lists.fedorahosted.org
> 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/[e-mail]...

[Matej Marusak]

On Wed, Feb 3, 2021 at 3:07 PM Tobias Vogel <tobias.vogel(a)linux.com&gt; 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 <mmarusak(a)redhat.com&gt; 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-...
> >
> >
> >
> > On Tue, Feb 2, 2021 at 7:38 PM Tobias Vogel <tobias.vogel(a)linux.com&gt;
> > 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 -- cockpit-devel(a)lists.fedorahosted.org
> >> To unsubscribe send an email to
> >> cockpit-devel-leave(a)lists.fedorahosted.org
> >> 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/[e-mail]...
> >>
> >
> > _______________________________________________
>  cockpit-devel mailing list -- cockpit-devel(a)lists.fedorahosted.org
>  To unsubscribe send an email to cockpit-devel-leave(a)lists.fedorahosted.org
>  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/[e-mail]...
>  

-- 

Matej Marušák

Senior Software Engineer

Red Hat

<https://www.redhat.com>
<https://red.ht/sig>

[Martin Pitt]

Hello Tobias,

Matej Marusak [2021-02-04 17:59 +0100]:
>  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) 
Please don't use /usr for these -- this is read-only package manager territory.
For a system-wide database, use /var/lib/myapp, for a per-user database use
~/.config/myapp or ~/.local/share/myapp

>  > 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. 
That not, but again, the installation directory of a cockpit page is a really
bad place for data.

Martin