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.

Close

What will be in 1.2? And how can I help?

2005-07-22
2013-05-21
  • Anders Nygren
    Anders Nygren
    2005-07-22

    Hi
    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.

    /Anders

     
    • Hi Anders,

      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)

      Quique

       
    • (Part II)

      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?

      Quique

       
    • Anders Nygren
      Anders Nygren
      2005-07-26

      Hi
      The message lenght must be a handset problem, I have made posts that are much longer.

      Anders

       
      • From the desktop, I can see now how short my messages were.  They seemed huge on a small screen :-)

         
    • (Part III)

      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 :-)

       
    • (Part IV)

      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.

      Best regards,