From mikemondragon at gmail.com Tue Nov 6 15:41:03 2007 From: mikemondragon at gmail.com (Mike Mondragon) Date: Tue, 6 Nov 2007 12:41:03 -0800 Subject: [mms2r-users] test Message-ID: <967d3b9a0711061241g7d05f0cet647a605afbf95f29@mail.gmail.com> test From mike at mondragon.cc Tue Nov 6 17:55:38 2007 From: mike at mondragon.cc (Mike Mondragon) Date: Tue, 06 Nov 2007 14:55:38 -0800 Subject: [mms2r-users] test Message-ID: <4730F0EA.10809@mondragon.cc> test From mikemondragon at gmail.com Thu Nov 8 16:45:45 2007 From: mikemondragon at gmail.com (Mike Mondragon) Date: Thu, 8 Nov 2007 13:45:45 -0800 Subject: [mms2r-users] MMS2R 2.0 features Message-ID: <967d3b9a0711081345u651ffc81k2519c8b3fed47f24@mail.gmail.com> There are four things I would like to do for a 2.0 release of MMS2R. Please give me your feedback if these are wise design decisions or if other features should be implemented. One: Refactor MMS2R's name space, decoupling "Media" from specific implementations. For instance MMS2R::NextelMedia would become MMS2R::Media::Nextel . Programs would still interact with the generic interface provided MMS2R::Media, only the classes that represent specif carriers would be pushed down one level deeper. Two: Make MMS2R::Media.new the factory method for the library rather than calling create() explicitly. That is idiomatic of Ruby. Three: Make processing of the MMS greedy within the initialize() method. Thus MMS2R::Media.new returns an object that has already called the process() method and programs don't have to call process() explicitly. However, a greedy flag will be available to initialize and if greedy is false then the program will have to call process() explicitly. Four: Define a generic Error class for MMS2R so that programs can implement rescuing behavior. Something such as: class MMS2RError < RuntimeError; end class NotProcessedError < MMS2RError; end class ProcessingError < MMS2RError; end For instance if an MMS2R object is created without being greedy then NotProcessedError should be raised if any of the MMS accessors are called such as subject() default_media() Also the network level errors that the Sprint class is susceptible to can be wrapped into ProcessingError -- Mike Mondragon Work> http://sas.quat.ch/ Blog> http://blog.mondragon.cc/ Small URLs> http://hurl.it/ From luke at slantwisedesign.com Mon Nov 12 12:17:05 2007 From: luke at slantwisedesign.com (Luke Francl) Date: Mon, 12 Nov 2007 11:17:05 -0600 Subject: [mms2r-users] MMS2R 2.0 features In-Reply-To: <967d3b9a0711081345u651ffc81k2519c8b3fed47f24@mail.gmail.com> References: <967d3b9a0711081345u651ffc81k2519c8b3fed47f24@mail.gmail.com> Message-ID: These all sound great to me. I think they'll make MMS2R easier to work with. I'd like to see more network coverage. I think we should have the most complete MMS library in any language (maybe we already do!). Any ideas on how we can achieve that? I can put out a call on my blog asking for submissions. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mms2r-users/attachments/20071112/3fad5799/attachment.html From luke at slantwisedesign.com Sun Nov 18 23:57:26 2007 From: luke at slantwisedesign.com (Luke Francl) Date: Sun, 18 Nov 2007 22:57:26 -0600 Subject: [mms2r-users] simplifying adding new carriers Message-ID: Hey, I'm writing instructions on how to add new carrier classes to MMS2R and while it's not difficult (even I figured out how to do it ;-), it's not as simple as it could be. One simple change that I think would make things easier would be if Media subclasses registered their email gateway mapping with the module's CARRIER_CLASSES hash. I think that's just as simple as something like this: class FoobarMedia < MMS2R::Media CARRIER_CLASSES['foobarmms.com'] => FoobarMedia end (or maybe a register method on the Media base class could be used to simplify things further). The other part is that MMS2R would have to load all the media subclasses when it's loaded. I think you talked about doing that with directory globing, right Mike? Does this sound reasonable? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mms2r-users/attachments/20071118/68b37bcc/attachment.html