Karmator icon indicating copy to clipboard operation
Karmator copied to clipboard

Implement a state store mechanics

Open pharaun opened this issue 9 years ago • 3 comments

For inspiration look at isla - https://github.com/klange/isla/blob/master/isla.py

But anyway basically same thing as the config.

plugin {
  pluginName :: templatehaskell thing
  persist/load config :: thingy
}

Might be easier to just make Plugin into a free monad stack, and/or use som sort of "stateT" extension to implement state loading/persisting but have that persist to the database.

Basically we can create something like this schema:

pluginName :: String
key :: String
blob :: ByteString

And have the plugins store the data that they care about as k -> v in the database with serialization to bytestring, we can probably do this automatic with the state monad/transformer thing if we give the right function.

pharaun avatar Jun 24 '15 19:06 pharaun

Probably can provide an alt way for "raw" access that is isolated to its own namespaced sqlite file/table

pharaun avatar Jun 30 '15 04:06 pharaun

This is implemented mostly in the Channels plugin. However its rather clunky and can be error prone because of the fact that the keys are stringified, and that we're using show/read serialization at the moment so its easy to mismatch the type.

I suspect that i can probably build up a framework (ie by the sqlWrapper) that set up all of these items and make it much more refined, and then a user could probably predefine a few key as a top-level func then just refer to these/wrap the get/modify/insert functions to pre-set the types maybe?

or having a dedicated serializer/deserializer would help (force the type this way), modify is also clunky because it takes the serializer + deserializer and yu can accidentally mismatch these.

pharaun avatar Jul 04 '15 08:07 pharaun

I wonder if we couldn't maybe use some sort of template haskell or maybe some higher function that would bundle all of the relevant pieces of data together in a nice unit (ie key, serializer, deserializer) then you could just refer/load/unload those for handling the serialization, then at a top-level somewhere have template haskell take in the plugin module and name it to be used in the key/etc. Which probably would go a long way toward making this whole interface more type-safe. There's still the open question of the type for the show/read instances but we can play around with that.

Maybe have the "key" be something like

autoJoinChannel network = PersistState
    { plugin = 'moduleName
    , serialize = showSerialize
    , deserialize = readDeserialize
    , key = T.concat [network, ",", "auto_join_channel"]
    }

modifyState autoJoinChannel (\a -> Set.insert (toString channel) a)

pharaun avatar Jul 04 '15 08:07 pharaun