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

Emil Ivov emcho at sip-communicator.org
Fri Sep 14 11:15:32 CEST 2007



Sympho wrote:
> done. It's a fun with the netbeans auto comment tool :)

Swell! Thanks for taking care of this!

Emil

> 
> ++
>> Thanks!
>> Emil
>>
>>
>>   
>>> 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
>>>
>>>
>>>     
>> ---------------------------------------------------------------------
>> 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