[sip-comm-dev] Alert for new yahoo mail

Sympho symphorien.wanko-tchuente at ulp.u-strasbg.fr
Fri Sep 14 01:45:10 CEST 2007

Hi all

Finally, we use the existing MessageReceivedEvent with the

Matthew, I understood your arguments and I adhere to them in great part. 
But, as Emil said,
the actual implementation may be viewed as a first step.

I provided a simple formatting for the message, it could be improved.


PS: I wrote some english in the formatted message. If someone knows
how to assure that those messages could be localized, its help will be 

Matthew Rubenstein a écrit :
> 	I've always found that an ounce of upfront design prevention is worth a
> pound of later retrofitting cure. We already know that we have a generic
> "incoming message event", with somewhat different functions (including
> different types of contained objects) in more specific types of those
> events. That is exactly when to use a base class (perhaps an abstract
> one) and at least a couple of subclasses. Rather than create a klugey
> flag in a class model that doesn't reflect the actual features of the
> system, that we already know is overloaded with improper semantics (is
> an email really a "system message"?) and will have to be deprecated, why
> not just set up the class hierarchy just a little differently, but
> correctly?
> 	In my experience, since we know up front before implementation that
> we're kluging such a basic OOP structure, we'll surely find before we're
> done implementing it that we should have used the proper class
> structure. Which is why I offered that kind of advice to the list a few
> weeks ago when we first started discussing the architecture of this very
> useful feature.
> On Mon, 2007-09-10 at 17:35 +0200, Emil Ivov wrote:
>> Hey Matt, Sympho,
>> I understand what you mean and it does make sense.
>> However, SIP Communicator is providing support for functionalities from
>> many different protocols, so it is sometimes quite tricky to determine
>> the best architecture for abstracting features.
>> We are generally trying to have 1 to 1 mappings for concepts that appear
>> with every protocol or that really need fine grained control from the
>> user interface like for example instant messages, presence events,
>> typing notifications and so on.
>> This is the first time we will be integrating anything about e-mail
>> notifications so a logical first step would be to try and use existing
>> abstractions.
>> Notifying the user that a new mail has arrived is quite straightforward.
>> Showing some text in the message area and making sure that it doesn't
>> look like an ordinary message seems like a nice start. (And I don't
>> really see why it would be a problem to put and html format any other
>> details in there).
>> If at some point we realize that:
>> a) this is not enough for using and showing all information that the
>> protocol has to offer
>> b) other protocols also do e-mail notifications
>> We would then try and come up with a list of things that are common to
>> all such protocols and mold some new abstractions (e.g. an email
>> notifications operation set) that would better represent them.
>> Does this make sense?
>> Emil
>> Sympho wrote:
>>> Hi all,
>>> Matthew Rubenstein a écrit :
>>>> 	Why use a flag in the event rather than a subclass for different
>>>> message types? What if the different type received needs different
>>>> methods or extra structured data?
>>> As Matthew said, it's possible to have several kind of message :
>>>     receiving a BuZZ, an alert (Yahoo alert) ...
>>> And for an email, perhaps the whole mail can be avaible or some 
>>> information on attached
>>> files ... I know we aren't writing a mail client, it is just to outline 
>>> the possible differences :)
>>> Perhaps having an overful number of events for messages looks awful but,
>>> even if we choose to use a flag, it would be interessant to have a more 
>>> comprehensive set
>>> of static fields (or enum, soon :) ) for messages distinction, rather 
>>> than flagging
>>> all messages events other than IM as SYSTEM_MESSAGE_RECEIVED.
>>> Sympho
>>>> On Mon, 2007-09-10 at 12:36 +0200, Yana Stamcheva wrote:
>>>>> Hi Sympho, Emil,
>>>>>>> Or, will it be better to have a
>>>>>>>     NewMailEvent
>>>>>>> for example ? (we can name it differently)
>>>>>>> So listeners can do what they want when a new mail is delivered.
>>>>>> I know that the UI is using some mechanism to distinguish certain
>>>>>> messages as system so that they appear differently to the user. I think
>>>>>> that e-mail notifications would be a perfect example of such messages so
>>>>>> you could probably deliver them this way. (Yana could probably give you
>>>>>> more details on this).
>>>>> Good idea. Actually in the MessageReceivedEvent you could find a special 
>>>>> event type SYSTEM_MESSAGE_RECEIVED which will make your message to be 
>>>>> displayed differently in the gui.
>>>>> Yana
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe at sip-communicator.dev.java.net
>>> For additional commands, e-mail: dev-help at sip-communicator.dev.java.net
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe at sip-communicator.dev.java.net
>> For additional commands, e-mail: dev-help at sip-communicator.dev.java.net

To unsubscribe, e-mail: dev-unsubscribe at sip-communicator.dev.java.net
For additional commands, e-mail: dev-help at sip-communicator.dev.java.net

More information about the dev mailing list