Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.
Can You tell me a little about what You are planning on including in 1.2?
Since we are planning a large project using oserl, I wonder how can I help? Rather than just "complaining" like I do now.
I'd like version 1.2 to include:
- Bug fixes.
- Use OTP/gen_fsm built-in timers.
- Remove the request_broker, start a timer instead of spawning a process per SMPP request.
- Review congestion state calculation.
- Use proc_lib:spawn_link .
- Error format.
These were already implemented.
There are other features to be included, I will comment in the next message (Continued)
Since most of us are probably writing logs and message fragmentation on our own, including support for these into OSERL 1.2 would be also nice.
I wrote a disk log (for PDU disk storage) and an error_logger based log (useful for debugging). I guess most of us came up with similar solutions in our SMPP developments. Comments are welcome.
Regarding message fragmentation...please read part III (reached max lenght...again :-( Is this my handset or a form's restriction?
The message lenght must be a handset problem, I have made posts that are much longer.
Enrique Marcote Peńa
From the desktop, I can see now how short my messages were. They seemed huge on a small screen :-)
I think we have a nice starting point to implement message fragmentation in our discussion. Some work needs to be done here.
- Move reference_number to the ESME/SMSC scope.
- Redefine message fragmentation. Add setup parameters as discussed.
- Add message concatenation on reception.
Finally I think we could redefine sessions using a common behaviour (say gen_session). Let me explain this point in part IV (sorry, I won't have access to a computer. During this week :-)
I'd like to define a gen_session behaviour. This new behaviour should be a FSM with all the code common to the gen_esme_session and the gen_smsc_session.
I think the gen_session behaviour could declare a callback for each SMPP state (open, outboubd, bound_tx, bound_rx, bound_trx and unbound). Then, the gen_esme_session/gen_smsc_session should implement these callbacks .
I you want, we could comment more on this issue.
Any help will be greatly appreciated. Thank you.