On Tuesday, October 25, 2016 at 8:08:11 AM UTC+1, Peter Damoc wrote: > > Why not just freeze dry your entire application state to some key/value >> store (on every update), then you have a simple way to rehydrate the whole >> application after a period of inactivity? >> > > This is not an option on large datasets. I gave the example with the Music > database in an earlier message specifically to address this. > Pagination is a very real concern that seldom appears in toy examples. >
Its not an option on shared data. Going with your MusicBrainz example, there is a shared data set. You could write an application that lets users read and write that data. I would think that such an application would only ever hold a small amount of the data at any one time, so serializing the application state is not the same thing as saving the whole MusicBrainz database. Also, this technique only saves the state for one user, there is no mechanism for integrating the changes made by several users into a single database. Here is an example where it would be relevant: a single player game. I might periodically dump the game state (perhaps not the entire Elm model, but enough to be able to continue playing from last position). Each users game state is their own, and I don't really care if they cheat, for example by using curl on the command line to poke at the persistence API, perhaps changing game level from 11 to 12 say. This is another very good reason that persistence is typically the concern of a server - globally, over the whole application state over all users, updates are being made concurrently. It is usually the responsibility of the server side to coordinate this concurrent state machine, in order to ensure it does not enter illegal states. The server is ideally positioned to take on this responsibility, being the hub in a hub and spokes model of your application. That said, a server centric model is not the only one possible. Client side storage, such as sessionStorage and localStorage and Web SQL database are relevant to Elm. I do think that these server side responsibilities are not really within the domain of Elm. -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to elm-discuss+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
