I keep on thinking how nicer it would be had smstools been using an sql database in the first place instead of generating temporary files.

What do you think?

Anyway, what's an alternative to getting the msgid that smst generates when I submit a message to the incoming spool? I'm attempting to develop an application that is using smstools in the backend. And I need to keep track of the messages being sent/received by each user, even while they're on qeue or in the spool.

There is no such kind of msgid which can be tracked when message is in the queue. But of course some additional header line can be used for this kind of purpose. However, spooling and sending does not take very long time, in many cases it has been enough to track when details of a sent message are available in the SQL database.

Generally taken your first idea sounds good. In the past I had plans to use SQL database for whole spooling, but I did not make this feature complete because another solution was used. I might do it in some day, but cannot promise anything large additions to the next version.

Basically, current sample of eventhandler inserts message to the database after message is sent, or sending has failed. With couple of additional columns new message could be inserted to database as a first step. It's status is then OUTGOING. Smsd mainprocess can check database like now outgoing directory, and make a spooling: If there is no queue (modem) defined, smsd can define it. In the similar way, each modem process can check database for outgoing messages which have correct modem defined. After a message has been found, modem process can just send it, change status to SENT (or FAILED) and fill up some fields like sent timestamp and messageid (for status report) etc. This way any filesystem spooling is not needed, but can still be used if necessary. For example mainprocess could still find message files from the outgoing directory and move them to queues, or to database.

Is this even close to what you have been thinking?

Yes, I've been reading the documentation and I realized that I can basically add any header for my own purpose, and smstools will simply ignore it. I should've done that in the first place.

Yes, your explanation about the database is exactly what I have in mind.

Right now, I'm using SQLite for this purpose. Of course, any sql database will work but SQLite is small and has enough features I am looking for. (no external dependencies, file based, etc.) If SQL database is built-in in future versions, it would be awesome!

I'm also working on a new smsevent script using python to eliminate the other dependencies, I'm going to share it as soon as I'm done with it. I was scratching my bald head why i'm not getting some of the headers and realized that the smsevent script depends on formail.

I agree. Although, basic sql queries can be combined with program (as far as, I read from forum threads), a built-in sql feature will significantly improve web-application capabilities of sms server.

Hi there, dragging this thread up from the distant past

I'm also very interested in the idea of using an SQL (specifically MySQL, but I'm sure that's not important) spooling system rather than the file based spool folders.

We currently have a mysql/php frontend interface for sending and receiving, the php both creates the spooling file, and records all the messages in the sql for history purposes. It seems to me that having a purely SQL spooling system would simplify the process of integrating the sms sending with web apps, without requiring access to the file system.

I'm wondering who has the knowledge and time to consider making this feature a reality? I would be very interested in discussing the cost of sponsoring this development.