Kalle Marjola wrote: >> Comments/votes please! >> > I did a quick test and seemed to work fine, thanks! > Some comments: > a) seems like the directory must exist already or bad things happen
hmm, store_init returns -1 if directory doesn't exists and it's up to higher layer to check this (bearerbox init code). I don't like the idea to create directory if it doesn't exists and also the idea to panic in this case. IMHO we have to much panics spread across kannel for such low level things and higher layer should check return values and make decisions. > b) should we rename config value it as 'store-dir' or 'store-spool-dir' > or something? yep, good point... 'store-dir' is a good one? > > otherwise +1 > >> P.S. should we have multiple types of store-file support in kannel? it >> would be easy to add config option like 'store-type=[file|spool]'. what >> are you think about? > > What would be the _real_ benefits of using the old 'file'? > If there really are, then yes, but otherwise not - maybe not need > backward compatibility? real benefit is that store spool dir is slower as e.g. store file + your patch (dict approach) (if your gateway has enough RAM to store messages twice). so user will make decision which type to use (but default: store-dir :)). > > > PS. Am I the only one who gets a bit annoyed of all the still reserved > memory areas reported when Kannel exits? Back in old times all of those > would have been cleansed... :] nope, you are not alone here... I have some fixes for this just merging is too time intensive :( > > -- Thanks, Alex
