Patriot Update: The Protocol Drivers
After committing the boiler codes for low-level protocol drivers to the Patriot, and reviewing the Kannel source[again] counterparts again. Things became clear, welcome to Kannel4J! Everything is becoming old school. Except that SAMS can optionally handle other stuff like billing info (both TC/SD and 0C). And the Content Providers' primary interface with the Network Operators will be thru JNDI to make implementation of mobile services uniform all throughout. And the JNDI is what the Nokia RI is lacking, it assumes that the SPI and Client implementation are co-located.
Tonight, I'll be working on the MMSC protocol drivers. And the last time I read the entire Kannel source was 2 years ago. This will force a lot of CPs in the future to use Java instead of other "toy" languages, not a bad thing really.
I'll sideline a bit. Fortunately, the SmsConnection and MmsConnection interface has an overloaded getConnection() method. The point of interest is the getConnection(Hashtable properties) where the client can pass some important parameters to the driver such as userid, password, tariff class, service description, billing indentifier and a whole lot of bits that can be passed to the UCP abstract data types for 50-series and 60-series type of operations. Way Cool!
Tonight, I'll be working on the MMSC protocol drivers. And the last time I read the entire Kannel source was 2 years ago. This will force a lot of CPs in the future to use Java instead of other "toy" languages, not a bad thing really.
I'll sideline a bit. Fortunately, the SmsConnection and MmsConnection interface has an overloaded getConnection() method. The point of interest is the getConnection(Hashtable properties) where the client can pass some important parameters to the driver such as userid, password, tariff class, service description, billing indentifier and a whole lot of bits that can be passed to the UCP abstract data types for 50-series and 60-series type of operations. Way Cool!
Comments