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


#1

Hi all,

This little patch provide a very basic mechanism to be alerted when
we receive a new Yahoo mail.
What do you think of it, and can we use it as is ?

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.

Of course we can also think of the same job for Msn or anything else (if possible).

regards.

yahoo.patch (2.51 KB)


#2

It would be best to have a generic event class for when any message
arrives (including incoming phone calls) with a subclass for each
message type (eg. IM, email, phonecall), with listening components for
both UI notification and internal dispatch (generate a new arbitrary
event). The event should include the name of the source (as well as the
rest of the event's profile data, like callerID, protocol, timestamps)
so the component that is triggered by the event can "do its thing", like
a display widget that shows the logo of the service that sent the event.

···

On Fri, 2007-08-31 at 15:35 +0200, Sympho wrote:

Hi all,

This little patch provide a very basic mechanism to be alerted when
we receive a new Yahoo mail.
What do you think of it, and can we use it as is ?

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.

Of course we can also think of the same job for Msn or anything else (if
possible).

regards.

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

--

(C) Matthew Rubenstein

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


#3

Hi Matthew,

As yout suggest, it could be nice to change some protocol events to have them subclasses of a generic one like
   ProtocolNotificationEvent
and have a
   ProtocolNotificationListener
Thus, listeners could register for only one event and use
   if (event instanceof SomeEvent)
to discriminate and take appropriate action.

But I think this is a little far from the first question :slight_smile:

For the mail alert, I am more inclined to have an appropriate event like
   MailReceivedEvent
rather than using
   MessageReceivedEvent
since it is not exactly the same thing, even if, we choose to notify the user with an IM for the moment.

regards.

Matthew Rubenstein <email@mattruby.com> a écrit :

···

  It would be best to have a generic event class for when any message
arrives (including incoming phone calls) with a subclass for each
message type (eg. IM, email, phonecall), with listening components for
both UI notification and internal dispatch (generate a new arbitrary
event). The event should include the name of the source (as well as the
rest of the event's profile data, like callerID, protocol, timestamps)
so the component that is triggered by the event can "do its thing", like
a display widget that shows the logo of the service that sent the event.

On Fri, 2007-08-31 at 15:35 +0200, Sympho wrote:

Hi all,

This little patch provide a very basic mechanism to be alerted when
we receive a new Yahoo mail.
What do you think of it, and can we use it as is ?

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.

Of course we can also think of the same job for Msn or anything else (if
possible).

regards.

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

--

(C) Matthew Rubenstein

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

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


#4

Hello Sympho,

I've just had a look at the patch and it looks quite nice.

(more inline)

Sympho wrote:

Hi all,

This little patch provide a very basic mechanism to be alerted when
we receive a new Yahoo mail.
What do you think of it, and can we use it as is ?

I think that we could start by sending such notifications as instant
messages (which is what you are currently doing).

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

Cheers
Emil

···

Of course we can also think of the same job for Msn or anything else (if
possible).

regards.

------------------------------------------------------------------------

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

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


#5

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@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#6

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?

···

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

--

(C) Matthew Rubenstein

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


#7

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 :slight_smile:

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 :slight_smile: ) 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@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#8

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 :slight_smile:

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 :slight_smile: ) 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@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

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


#9

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 :slight_smile:
>
> 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 :slight_smile: ) 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@sip-communicator.dev.java.net
> For additional commands, e-mail: dev-help@sip-communicator.dev.java.net
>
>

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

--

(C) Matthew Rubenstein


#10

Hi!
In MediaControl.java in line 562

  if (transmittableAudioEncodings.contains(sdp))

I think, there is a ! missing

  if (!transmittableAudioEncodings.contains(sdp))

as it is with the videoformats.

Any coments?
Regards, thomas

···

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


#11

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 :slight_smile:

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 :slight_smile: ) 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@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

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

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


#12

Hi,

yes you are right!. Will be fixed.

Thanks,
damencho

···

On 9/11/07, Thomas Hofer <mailinglisten@familie-hofer.net> wrote:

Hi!
In MediaControl.java in line 562

        if (transmittableAudioEncodings.contains(sdp))

I think, there is a ! missing

        if (!transmittableAudioEncodings.contains(sdp))

as it is with the videoformats.

Any coments?
Regards, thomas

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

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


#13

Well, at least we've got some design docs for the next round of
implementation.

···

On Fri, 2007-09-14 at 01:45 +0200, Sympho wrote:

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 :slight_smile:
>>>
>>> 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 :slight_smile: ) 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@sip-communicator.dev.java.net
>>> For additional commands, e-mail: dev-help@sip-communicator.dev.java.net
>>>
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
>> For additional commands, e-mail: dev-help@sip-communicator.dev.java.net
>>
>>

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

--

(C) Matthew Rubenstein

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


#14

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.

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

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 :slight_smile:

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 :slight_smile: ) 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@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

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

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

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


#15

Hi,

just to report that I've just committed the fix.
Nice catch! And thanks once again.

damencho

Damian Minkov wrote:

···

Hi,

yes you are right!. Will be fixed.

Thanks,
damencho

On 9/11/07, Thomas Hofer <mailinglisten@familie-hofer.net> wrote:
  

Hi!
In MediaControl.java in line 562

        if (transmittableAudioEncodings.contains(sdp))

I think, there is a ! missing

        if (!transmittableAudioEncodings.contains(sdp))

as it is with the videoformats.

Any coments?
Regards, thomas

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

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


#16

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.

:slight_smile:

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 :slight_smile:

···

++

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 :slight_smile:

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 :slight_smile: ) 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@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

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

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

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

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


#17

Sympho wrote:

done. It's a fun with the netbeans auto comment tool :slight_smile:

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 :slight_smile:

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 :slight_smile: ) 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@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

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

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

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

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

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