None of the users' files should get touched during an update... tool tables, .hal and .ini files, etc.
If we are worried about breaking the sqlite tool table file there are far larger issues and you better not be touching user files, at least not without asking if they want to keep the old, new, or merge the two (debian has facilities for doing this on package install). Also, as a long time computer user and admin... if you don't back up key data and user files before doing a an update that might break things you are asking for trouble. Do we start worrying about how they rebuild their system after a HDD failure? A production machine shouldn't get updated anyway unless there is a new functionality or bug fix that is needed. While an SQLite database file does have some binary data in it, mostly for schema stuff, most of the user data is actually stored as plain text. This is why I specifically mentioned it. We aren't dealing with a large enough data set that we need the space savings and search optimization of a more advanced DB engine. As Ken said, there isn't a running background service, and it would likely only add a couple of dependencies. What SQLite gets us is a very nice and well supported toolset for interacting with that data without having to write your own parser. If someone writes a new interface, they can easily interact with the SQLite DB without having to create a new parser. C++ and python calls are easy to implement in the code. I just checked the latest 2.7 install with updates to 2.7.7 and the C library for SQLite is installed by default. The cli interface and python and tcl bindings are not. We may find that sqlitebrowser is a good enough solution for editing the tooltable file. I have only used it briefly once. Just my continued thoughts... YMMV On 10/26/2016 02:50 PM, James Waples wrote: > Although the interface is well defined, the database itself is still an > opaque binary blob. What happens if a library upgrade breaks a user's file > in the wild? It's easier to hand-/auto-repair a plaintext file, whatever > format that's in. Moving to binaries is a regression in my opinion. > > On Wed, 26 Oct 2016 at 19:00 Kenneth Lerman <ler...@se-ltd.com> wrote: > >> SQLite is just another library. Yes, it is another dependency. But it >> should be no more an issue than libc or libm or any other library. Unlike >> mysql or postgresql, it does not require a separately running executable. >> >> Ken >> >> Kenneth Lerman >> 55 Main Street >> Newtown, CT 06470 >> >> >> On Wed, Oct 26, 2016 at 11:07 AM, EBo <e...@sandien.com> wrote: >> >>> Then you are requiring SQLite in the dependency chain. Is that more >>> maintainable than not? >>> >>> On Oct 26 2016 8:51 AM, Kenneth Lerman wrote: >>>> I would go with SQLite. And a text (and/or JSON and/or YAML and/or >>>> ...) >>>> interface. >>>> >>>> But the change must provide all of the necessary tools: >>>> 1 -- a tool table editor >>>> 2 -- a flat file, text interface >>>> 3 -- JSON or YAML interface >>>> 4 -- a way to read the tool table at startup >>>> 5 -- a way to access (the necessary parts of) the tool table at run >>>> time. >>> >>>> >>>> On Wed, Oct 26, 2016 at 7:00 AM, EBo <e...@sandien.com> wrote: >>>> >>>>> ... I was not aware of the 59 item limit. 256 (8-bit int) or >>>>> 64K (16-bit int) seems more reasonable. For James example I would >>>>> lean >>>>> towards a 16-bit tool number. It is also possible that some of the >>>>> bits >>>>> could be used for status indication and we actually end up with >>>>> something like 12-bits of tool numbers and 4 bits for status. >>>>> >>>> >>>> This is NOT 1980. Memory (at this level) is free. There is no need to >>>> pack >>>> bits, save memory, or worry about stuff like this. >>> >>> True. I guess I am showing both my age and occupation -- last year I >>> was handed a 2.4 Petabyte dataset to process. There, doubling the >>> output by not packing the bits would increase the output by a full >>> petabyte (which costs something like $100K to install and maintain for >>> the project lifetime). For LinuxCNC you are correct -- it is not worth >>> the time, headaches, or space. >>> >>> EBo -- >>> >>> ------------------------------------------------------------ >>> ------------------ >>> The Command Line: Reinvented for Modern Developers >>> Did the resurgence of CLI tooling catch you by surprise? >>> Reconnect with the command line and become more productive. >>> Learn the new .NET and ASP.NET CLI. Get your free copy! >>> http://sdm.link/telerik >>> _______________________________________________ >>> Emc-developers mailing list >>> Emc-developers@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/emc-developers >>> >> >> ------------------------------------------------------------------------------ >> The Command Line: Reinvented for Modern Developers >> Did the resurgence of CLI tooling catch you by surprise? >> Reconnect with the command line and become more productive. >> Learn the new .NET and ASP.NET CLI. Get your free copy! >> http://sdm.link/telerik >> _______________________________________________ >> Emc-developers mailing list >> Emc-developers@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/emc-developers >> > ------------------------------------------------------------------------------ > The Command Line: Reinvented for Modern Developers > Did the resurgence of CLI tooling catch you by surprise? > Reconnect with the command line and become more productive. > Learn the new .NET and ASP.NET CLI. Get your free copy! > http://sdm.link/telerik > _______________________________________________ > Emc-developers mailing list > Emc-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-developers >
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ The Command Line: Reinvented for Modern Developers Did the resurgence of CLI tooling catch you by surprise? Reconnect with the command line and become more productive. Learn the new .NET and ASP.NET CLI. Get your free copy! http://sdm.link/telerik
_______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
