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

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


Hi,

Emil Ivov a écrit :
> Hello Sympho,
>
> This is cool! It's a shame I am not using Yahoo! Mail but it does sound
> like a nice feature.
>
>   
:)
>> 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.
>>     
>
> Most of the UI code and as well as the account wizards have
> internationalization you could have a look at these.
>
>   
done.
> Incidentally, could you please add some javadocs for the newly added
> method? I also saw that there were some other  methods around it that
> have slipped in without comments from the previous developer so it would
> be quite nice of you if you could also add a word or two on them too.
> (If you can of course.)
>
>   
done. It's a fun with the netbeans auto comment tool :)

++
> 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





More information about the dev mailing list