[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
SYSTEM_MESSAGE_RECEIVED flag.

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.

Regards
    Sympho.


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

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