[sip-comm-dev] [PATCH] Official Submission for SC-Avmailbox


#1

Well, here it is. Attached is the code from my Summer of Code project
for the mailbox.

First, a few notes on the attachments:
-I think I did the diff syntax right, but let me know if I flubbed
something up.
-The binary files (one icon and one sound file) are included in a
separate archive so as not to ugly up the patch.

Also, a few notes on the content:
-The default outgoing message is me. Let me know if y'all need any
sort of licensing documentation or copyright-transferral
whachamahoozits.
-The Icon for the Mailbox's entry in the configuration window is taken
from the Tango Desktop Project. It seemed to fit and I am lazy (and no
artist!). I originally considered it a placeholder, but if we want to
use it It seems that we could. Their licensing conditions are CC
Attribution-Share Alike (available here:
http://creativecommons.org/licenses/by-sa/2.5/). I don't know how we'd
go about attributing them, so I will leave the decision as to how to
handle that (or make a new icon entirely) up to someone with more
know-how.
-There's a few limitations to the Mailbox that are probably worth
mentioning. I don't do any sort of compatibility checking on the
user's choice of an outgoing message, mostly because JMF is a bit of a
quagmire already in this area and we are planning a migration to FMJ
which might change the list of compatible formats even more. I highly
recommend testing a file in JMStudio before you use it as your
outgoing message
-Incoming messages are now just Audio. This one's high on my to-do list.

Other than that, things should pretty much work as expected. I'd
really like to continue contributing to the project even after the
Summer comes to a close, so please let me know if there are some
additional Mailbox features that are highly desirable.

sc-avmailbox.patch (200 KB)

sc-avmailbox.binary.zip (212 KB)

···

--
Ryan Ricard
evilhecubus@gmail.com
ryan.ricard@student.utdallas.edu


#2

Hello Ryan,

I've just finished my review of the mailbox patch. Very good job! Having
to do with the media service is never an easy job and I think that
you've handled it quite nicely. Also, your code is straightforward and
easy to read!

Following is a list of modifications (most of which are only a matter of
form) that I have made before committing your work.

I'd be grateful if you could review them on your turn in case I've
messed something up. Besides, I haven't tested the code after my changes
so it is very likely that I have broken one or two things.

Right now the code is committed but it won't build and run by default.
We'll turn it on once we have verified it works and that all the basic
functionality is there.

So here's the list:

* I've removed from the patch some bak and .# files that seem to have
slipped there unintentionally. Here's the list: .#MediaServiceImpl.java,
CallSessionImpl.java.bak, MediaControl.java.bak,
MediaServiceImpl.java.bak, .#NightlyBuildID.java, NightlyBuildID.java,
MediaServiceJava.bak

* Generally, I've changed all catch log statements that looked liked this:
    catch(Exception exc)
    {
        logger.error("An exception has occurred: " + exc );
    }
to look like this:
    catch(Exception exc)
    {
        logger.error("An exception has occurred.", exc );
    }
so that the stack trace would also appear in logs.

* build.xml - replaced nominative references to the src and classes
directories with the corresponding ant variables (\{src\}, and {dest})

* I've decided to move the whole thing from impl to plugin. I don't
remember whether we have discussed this previously, and I apologise if
it was me who told you to place your work inside impl, but since it is
not an implementation of an existing service, I thought that it would be
better suited for plugin.

* I've moved all resources from inside the plugin to the common resource
tree in the root.

* MailboxActivator.java:

-- Added javadoc comments on all private class fields.

-- Removed logEntry()/logExit() logs ( I know that they still exist in
some places but they are not part of the convention any more, and since
we have other logging in the same method, I thought that we don't really
need the trace prints.

-- added @param javadocs for stop()

-- currently you are only checking whether the configuration form is
there when you start. Can you please consider registering a listener
with the bundle context, that would also allow you to add your config
form even if the UI implementation gets loaded after you?

-- Added a getFileAccessService() method that we'd need in Mailbox.java

* Mailbox.java

-- I've added comments for all private fields. Can you please consider
review-ing them in case I've misunderstood something?

-- I've noticed that javadoc comments are often not aligned as they
should be, so I thought I'd post an example here (though most of your
comments were ok ...):

    /**
     * bodybodybody
     * bodybodybody

···

*
     * @param param1 text text text
     */

(notice how all asterisk symbols are in the same column, and that
there's an empty space after each one of them)

-- I didn't find the tape.png and default_outgoing_mesage.wav resouce
files so I've fetched them from your av-mailbox repository. Let me know
if they are not the version that you intended to submit.

-- Set mailbox threads to daemon or otherwise they would prevent the
application from exiting while active. I've also added a name for them.

-- I've renamed the AnswerIncomingCall inner class to
IncomingCallTracker. Class names are generally supposed to be nouns, and
method names - verbs:
http://java.sun.com/docs/books/jls/second_edition/html/names.doc.html#29466

-- I've extracted several sub-methods from the run method of the same
thread in order to make it easier to read.

-- I've split the try/catch block in the same run method to several
subblocks. It is generally a good idea to avoid stuffing a lot of
exception throwing methods in the same try{}catch(){} clause. There's a
very good article that appeared in JDJ a while ago that dwells on the
subject (a very interesting read):

http://jdj.sys-con.com/read/37416_p.htm

-- A suggestion. Wouldn't it be a better idea to have file names stamped
in a more user friendly way? I was thinking about including the name of
the first call participant, and possibly a human readable date. We don't
seem to be having a user interface for the mailbox right now so this
would definitely ease testing.

* MediaService

-- I've renamed the "Destination" suffix in your methods to "Sink".
There were two reasons for this. First, destination makes me think of a
remote place and is often associated with networks. I wanted this to
look more as something local so I've chosen sink since this is also a
term employed by JMF. How does this sound? Let me know if something is
bothering you.

-- Wouldn't it be better to have the get duration return milliseconds?

-- Having the file name as the sole parameter when setting a data sink
might be insufficient. Don't you think that we should also content
descriptors explaining the formats that we'd like to be recorded in this
file?

-- I am wondering (and I'd really like to have your opinion here)
whether it wouldn't be better to give more granularity to the media
service, and kind of make it look like a _very_ simplified JMF? I am
thinking about having separate DataSource and DastaSink interfaces for
example, that would be created and mapped to calls through the
MediaService. Sympho has already suggested in a previous mail that
CallSession for example turns out to be inappropriate for jabber/jingle
so we are probably going to have an RtpFlow interface soon, so that's
also what was making me think that the MediaService should generally
allow for more flexibility.

* MediaServiceImpl

-- I've renamed some of the fields you added (nothing important though)

-- This one is _very_important_. Unless I've missed something, it seems
to me that when defining call sink and media control mappings you are
not doing anything to make sure you remove them when the call ends. This
means that you'll keep a reference to them even after they are no longer
relevant and both the call, and the mediacontrol/data sink will never
get garbage collected. Could you please fix this?

* CallSessionImpl

-- I feel a bit uncomfortable with the fact that you are hard setting
the output file type to WAV. I've also mentioned this in the
MediaService comments - I think we'd have to specify this when setting
the data sink.

-- I've removed the video handling code in here. Had you tested it? I
have trouble understanding how it works, provided you hard set the file
type to WAV, and weren't there any problems coming from the fact that
you write to the same file from 2 different streams/threads?

So I guess that's it, I'd really appreciate it if you could make sure
that everything still works after my changes.

Cheers, and thank you for contributing!
Emil

Ryan Ricard wrote:

Well, here it is. Attached is the code from my Summer of Code project
for the mailbox.

First, a few notes on the attachments:
-I think I did the diff syntax right, but let me know if I flubbed
something up.
-The binary files (one icon and one sound file) are included in a
separate archive so as not to ugly up the patch.

Also, a few notes on the content:
-The default outgoing message is me. Let me know if y'all need any
sort of licensing documentation or copyright-transferral
whachamahoozits.
-The Icon for the Mailbox's entry in the configuration window is taken
from the Tango Desktop Project. It seemed to fit and I am lazy (and no
artist!). I originally considered it a placeholder, but if we want to
use it It seems that we could. Their licensing conditions are CC
Attribution-Share Alike (available here:
http://creativecommons.org/licenses/by-sa/2.5/). I don't know how we'd
go about attributing them, so I will leave the decision as to how to
handle that (or make a new icon entirely) up to someone with more
know-how.
-There's a few limitations to the Mailbox that are probably worth
mentioning. I don't do any sort of compatibility checking on the
user's choice of an outgoing message, mostly because JMF is a bit of a
quagmire already in this area and we are planning a migration to FMJ
which might change the list of compatible formats even more. I highly
recommend testing a file in JMStudio before you use it as your
outgoing message
-Incoming messages are now just Audio. This one's high on my to-do list.

Other than that, things should pretty much work as expected. I'd
really like to continue contributing to the project even after the
Summer comes to a close, so please let me know if there are some
additional Mailbox features that are highly desirable.

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

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


#3

Thanks Emil! Thanks especially for making all those little form
changes. I'll reply to all the questions you asked me inline.

Hello Ryan,

I've just finished my review of the mailbox patch. Very good job! Having
to do with the media service is never an easy job and I think that
you've handled it quite nicely. Also, your code is straightforward and
easy to read!

I really appreciate the compliment!

Following is a list of modifications (most of which are only a matter of
form) that I have made before committing your work.

I'd be grateful if you could review them on your turn in case I've
messed something up. Besides, I haven't tested the code after my changes
so it is very likely that I have broken one or two things.

Right now the code is committed but it won't build and run by default.
We'll turn it on once we have verified it works and that all the basic
functionality is there.

So here's the list:

* I've removed from the patch some bak and .# files that seem to have
slipped there unintentionally. Here's the list: .#MediaServiceImpl.java,
CallSessionImpl.java.bak, MediaControl.java.bak,
MediaServiceImpl.java.bak, .#NightlyBuildID.java, NightlyBuildID.java,
MediaServiceJava.bak
* Generally, I've changed all catch log statements that looked liked this:
    catch(Exception exc)
    {
        logger.error("An exception has occurred: " + exc );
    }
to look like this:
    catch(Exception exc)
    {
        logger.error("An exception has occurred.", exc );
    }
so that the stack trace would also appear in logs.
* build.xml - replaced nominative references to the src and classes
directories with the corresponding ant variables (${src}, and ${dest})

* I've decided to move the whole thing from impl to plugin. I don't
remember whether we have discussed this previously, and I apologise if
it was me who told you to place your work inside impl, but since it is
not an implementation of an existing service, I thought that it would be
better suited for plugin.

* I've moved all resources from inside the plugin to the common resource
tree in the root.

* MailboxActivator.java:

-- Added javadoc comments on all private class fields.

-- Removed logEntry()/logExit() logs ( I know that they still exist in
some places but they are not part of the convention any more, and since
we have other logging in the same method, I thought that we don't really
need the trace prints.

-- added @param javadocs for stop()

-- currently you are only checking whether the configuration form is
there when you start. Can you please consider registering a listener
with the bundle context, that would also allow you to add your config
form even if the UI implementation gets loaded after you?

Yeah, no problem.

-- Added a getFileAccessService() method that we'd need in Mailbox.java

* Mailbox.java

-- I've added comments for all private fields. Can you please consider
review-ing them in case I've misunderstood something?

-- I've noticed that javadoc comments are often not aligned as they
should be, so I thought I'd post an example here (though most of your
comments were ok ...):

    /**
     * bodybodybody
     * bodybodybody
     *
     * @param param1 text text text
     */

(notice how all asterisk symbols are in the same column, and that
there's an empty space after each one of them)

-- I didn't find the tape.png and default_outgoing_mesage.wav resouce
files so I've fetched them from your av-mailbox repository. Let me know
if they are not the version that you intended to submit.

I had them attached to the first message I sent, but they weren't in
the patch. But you've got the correct files so it's all good :slight_smile:

-- Set mailbox threads to daemon or otherwise they would prevent the
application from exiting while active. I've also added a name for them.
-- I've renamed the AnswerIncomingCall inner class to
IncomingCallTracker. Class names are generally supposed to be nouns, and
method names - verbs:
http://java.sun.com/docs/books/jls/second_edition/html/names.doc.html#29466

-- I've extracted several sub-methods from the run method of the same
thread in order to make it easier to read.

-- I've split the try/catch block in the same run method to several
subblocks. It is generally a good idea to avoid stuffing a lot of
exception throwing methods in the same try{}catch(){} clause. There's a
very good article that appeared in JDJ a while ago that dwells on the
subject (a very interesting read):

http://jdj.sys-con.com/read/37416_p.htm

-- A suggestion. Wouldn't it be a better idea to have file names stamped
in a more user friendly way? I was thinking about including the name of
the first call participant, and possibly a human readable date. We don't
seem to be having a user interface for the mailbox right now so this
would definitely ease testing.

Oh yeah, I hadn't realized that the name of the call participant was
so readily available. How does 'Message.Name.MMDDYYYYHHMMSS.wav'
sound?

* MediaService

-- I've renamed the "Destination" suffix in your methods to "Sink".
There were two reasons for this. First, destination makes me think of a
remote place and is often associated with networks. I wanted this to
look more as something local so I've chosen sink since this is also a
term employed by JMF. How does this sound? Let me know if something is
bothering you.

Oh no, that is fine. I wasn't sure if 'sink' was used outside of JMF
and didn't want the naming to suggest that the mailbox was JMF
specific. But 'Sink' is a more descriptive name anyway.

-- Wouldn't it be better to have the get duration return milliseconds?

Yeah. That's probably a better idea.

-- Having the file name as the sole parameter when setting a data sink
might be insufficient. Don't you think that we should also content
descriptors explaining the formats that we'd like to be recorded in this
file?

That makes sense. Is there a straightforward way in JMF to test
whether or not we can record in a particular format?

-- I am wondering (and I'd really like to have your opinion here)
whether it wouldn't be better to give more granularity to the media
service, and kind of make it look like a _very_ simplified JMF? I am
thinking about having separate DataSource and DastaSink interfaces for
example, that would be created and mapped to calls through the
MediaService. Sympho has already suggested in a previous mail that
CallSession for example turns out to be inappropriate for jabber/jingle
so we are probably going to have an RtpFlow interface soon, so that's
also what was making me think that the MediaService should generally
allow for more flexibility.

Yeah, that makes sense. It seems counter-intuitive, for instance, that
the DataSource for a call is handled by the MediaControl object and
the DataSink for a call is handled by CallSessionImpl.

* MediaServiceImpl

-- I've renamed some of the fields you added (nothing important though)

-- This one is _very_important_. Unless I've missed something, it seems
to me that when defining call sink and media control mappings you are
not doing anything to make sure you remove them when the call ends. This
means that you'll keep a reference to them even after they are no longer
relevant and both the call, and the mediacontrol/data sink will never
get garbage collected. Could you please fix this?

Look at the CallEnded() method within Mailbox.java. That's where I'm
calling MediaService.unsetCallDataSink() and
MediaService.unsetCallDataSource(). Those two methods release the
mappings in question. Let me know if there's anything else that needs
to be done to make sure that the GC takes care of those objects.

* CallSessionImpl

-- I feel a bit uncomfortable with the fact that you are hard setting
the output file type to WAV. I've also mentioned this in the
MediaService comments - I think we'd have to specify this when setting
the data sink.

Right now the reason that it is hard set to WAV is that I hadn't yet
come up with a way to know ahead of time what formats we can encode in
using JMF. WAV was a known quantity, so I went with it until I figured
out a better way to choose from a list of incoming message file types.
But yes, getting it to the point that we can record in other formats
is definitely a goal.

-- I've removed the video handling code in here. Had you tested it? I
have trouble understanding how it works, provided you hard set the file
type to WAV, and weren't there any problems coming from the fact that
you write to the same file from 2 different streams/threads?

I think what you are looking at is the code that used to handle the
video display (not my code). I think this code got replaced somewhere
along the line and I forgot to keep it out of the patch. sorry.

So I guess that's it, I'd really appreciate it if you could make sure
that everything still works after my changes.

Actually... your changes in the IncomingCallTracker.run() method,
though they add greatly to readability, cause the program to infinite
loop ;p.

I'll put the fix in along with some of the other little things you
mentioned in your message and send it in a new patch.

Cheers, and thank you for contributing!
Emil

No problem. I'm excited to see my changes merged into mainline!

···

Ryan Ricard wrote:
> Well, here it is. Attached is the code from my Summer of Code project
> for the mailbox.
>
> First, a few notes on the attachments:
> -I think I did the diff syntax right, but let me know if I flubbed
> something up.
> -The binary files (one icon and one sound file) are included in a
> separate archive so as not to ugly up the patch.
>
> Also, a few notes on the content:
> -The default outgoing message is me. Let me know if y'all need any
> sort of licensing documentation or copyright-transferral
> whachamahoozits.
> -The Icon for the Mailbox's entry in the configuration window is taken
> from the Tango Desktop Project. It seemed to fit and I am lazy (and no
> artist!). I originally considered it a placeholder, but if we want to
> use it It seems that we could. Their licensing conditions are CC
> Attribution-Share Alike (available here:
> http://creativecommons.org/licenses/by-sa/2.5/). I don't know how we'd
> go about attributing them, so I will leave the decision as to how to
> handle that (or make a new icon entirely) up to someone with more
> know-how.
> -There's a few limitations to the Mailbox that are probably worth
> mentioning. I don't do any sort of compatibility checking on the
> user's choice of an outgoing message, mostly because JMF is a bit of a
> quagmire already in this area and we are planning a migration to FMJ
> which might change the list of compatible formats even more. I highly
> recommend testing a file in JMStudio before you use it as your
> outgoing message
> -Incoming messages are now just Audio. This one's high on my to-do list.
>
> Other than that, things should pretty much work as expected. I'd
> really like to continue contributing to the project even after the
> Summer comes to a close, so please let me know if there are some
> additional Mailbox features that are highly desirable.
>
>
>
> ------------------------------------------------------------------------
>
> ---------------------------------------------------------------------
> 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

--
Ryan Ricard
evilhecubus@gmail.com
ryan.ricard@student.utdallas.edu

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


#4

Hi Ryan,

Ryan Ricard wrote:

-- I didn't find the tape.png and default_outgoing_mesage.wav resouce
files so I've fetched them from your av-mailbox repository. Let me know
if they are not the version that you intended to submit.

I had them attached to the first message I sent, but they weren't in
the patch. But you've got the correct files so it's all good :slight_smile:

Oh ... I wonder where my head was when I wrote this. You are right,
sorry I missed it.

-- A suggestion. Wouldn't it be a better idea to have file names stamped
in a more user friendly way? I was thinking about including the name of
the first call participant, and possibly a human readable date. We don't
seem to be having a user interface for the mailbox right now so this
would definitely ease testing.

Oh yeah, I hadn't realized that the name of the call participant was
so readily available. How does 'Message.Name.MMDDYYYYHHMMSS.wav'
sound?

How about 'Message.YYYYMMDDHHMMSS.Name.wav'? This way they'd be order
chronologically when listing the contents of the directory.

* MediaService
-- Having the file name as the sole parameter when setting a data sink
might be insufficient. Don't you think that we should also content
descriptors explaining the formats that we'd like to be recorded in this
file?

That makes sense. Is there a straightforward way in JMF to test
whether or not we can record in a particular format?

This is a lucky coincidence :). The latest patch from Sympho contained
just the methods we need. Have a look at

public String[] getSupportedAudioEncodings();
public String[] getSupportedVideoEncodings();

This makes me think however that we should probably add a number of
static fields for the most popular encodings. Could you please do this
if you have the time to? You could have a look at the media control
class for the definitions (that are actually the standard SDP ones).

-- I am wondering (and I'd really like to have your opinion here)
whether it wouldn't be better to give more granularity to the media
service, and kind of make it look like a _very_ simplified JMF? I am
thinking about having separate DataSource and DastaSink interfaces for
example, that would be created and mapped to calls through the
MediaService. Sympho has already suggested in a previous mail that
CallSession for example turns out to be inappropriate for jabber/jingle
so we are probably going to have an RtpFlow interface soon, so that's
also what was making me think that the MediaService should generally
allow for more flexibility.

Yeah, that makes sense. It seems counter-intuitive, for instance, that
the DataSource for a call is handled by the MediaControl object and
the DataSink for a call is handled by CallSessionImpl.

I agree, so we'd have to think of the new interfaces to add. DataSource
and DataSink seem like an obvious choice, though I am not sure what
exactly are the methods that they should contain.

I also wanted to simplify the CallSession and have all the sdp
decoding/encoding functionality in a separate place.

* MediaServiceImpl

-- This one is _very_important_. Unless I've missed something, it seems
to me that when defining call sink and media control mappings you are
not doing anything to make sure you remove them when the call ends. This
means that you'll keep a reference to them even after they are no longer
relevant and both the call, and the mediacontrol/data sink will never
get garbage collected. Could you please fix this?

Look at the CallEnded() method within Mailbox.java. That's where I'm
calling MediaService.unsetCallDataSink() and
MediaService.unsetCallDataSource(). Those two methods release the
mappings in question. Let me know if there's anything else that needs
to be done to make sure that the GC takes care of those objects.

Oh yes true! Sorry I missed it.

Do you think that it would be a good idea to also add a call listener
inside the media service itself in order to make sure that we remove the
call, even if the plugin (that might other than the mailbox) is not
doing it?

* CallSessionImpl

-- I've removed the video handling code in here. Had you tested it? I
have trouble understanding how it works, provided you hard set the file
type to WAV, and weren't there any problems coming from the fact that
you write to the same file from 2 different streams/threads?

I think what you are looking at is the code that used to handle the
video display (not my code). I think this code got replaced somewhere
along the line and I forgot to keep it out of the patch. sorry.

I am talking about line 1693-1700 in the patch that look like this

+ logger.info("starting recording to file: "+dataDestination);
+ MediaLocator dest = new MediaLocator(dataDestination);
+ DataSource ds = ((Processor)player).getDataOutput();
+ DataSink sink = Manager.createDataSink(((Processor)player).getDataOutput(), dest);
+ player.start();
+ //do we know the output file's duration
+ StartRecording record = new StartRecording(sink);
+ record.run();

as well as the StartRecording thread. Don't they record in the same file
as the audio .... or am I missing something?

So I guess that's it, I'd really appreciate it if you could make sure
that everything still works after my changes.

Actually... your changes in the IncomingCallTracker.run() method,
though they add greatly to readability, cause the program to infinite
loop ;p.

... well they are readable aren't they? It should be easy to find the
problem now :). Seriously, sorry for braking the code. I didn't have the
time to test it. Will be more careful next time.

I'll put the fix in along with some of the other little things you
mentioned in your message and send it in a new patch.

Cheers, and thank you for contributing!
Emil

No problem. I'm excited to see my changes merged into mainline!

Glad you are!

By the way, are you planning on writing some user interface that would
alert users when they have new messages, and allow them to play, store
and delete them?

Offering the possibility to record a new outgoing message through SIP
Communicator, as well as playing the existing one also seems like a
useful feature. Interested in taking this up?

Cheers
Emil

···

Ryan Ricard wrote:

Well, here it is. Attached is the code from my Summer of Code project
for the mailbox.

First, a few notes on the attachments:
-I think I did the diff syntax right, but let me know if I flubbed
something up.
-The binary files (one icon and one sound file) are included in a
separate archive so as not to ugly up the patch.

Also, a few notes on the content:
-The default outgoing message is me. Let me know if y'all need any
sort of licensing documentation or copyright-transferral
whachamahoozits.
-The Icon for the Mailbox's entry in the configuration window is taken
from the Tango Desktop Project. It seemed to fit and I am lazy (and no
artist!). I originally considered it a placeholder, but if we want to
use it It seems that we could. Their licensing conditions are CC
Attribution-Share Alike (available here:
http://creativecommons.org/licenses/by-sa/2.5/). I don't know how we'd
go about attributing them, so I will leave the decision as to how to
handle that (or make a new icon entirely) up to someone with more
know-how.
-There's a few limitations to the Mailbox that are probably worth
mentioning. I don't do any sort of compatibility checking on the
user's choice of an outgoing message, mostly because JMF is a bit of a
quagmire already in this area and we are planning a migration to FMJ
which might change the list of compatible formats even more. I highly
recommend testing a file in JMStudio before you use it as your
outgoing message
-Incoming messages are now just Audio. This one's high on my to-do list.

Other than that, things should pretty much work as expected. I'd
really like to continue contributing to the project even after the
Summer comes to a close, so please let me know if there are some
additional Mailbox features that are highly desirable.

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

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


#5

Hi again Ryan,

(inline)

Emil Ivov wrote:

-- I've removed the video handling code in here. Had you tested it? I
have trouble understanding how it works, provided you hard set the file
type to WAV, and weren't there any problems coming from the fact that
you write to the same file from 2 different streams/threads?

I think what you are looking at is the code that used to handle the
video display (not my code). I think this code got replaced somewhere
along the line and I forgot to keep it out of the patch. sorry.

I am talking about line 1693-1700 in the patch that look like this

+ logger.info("starting recording to file: "+dataDestination);
+ MediaLocator dest = new MediaLocator(dataDestination);
+ DataSource ds = ((Processor)player).getDataOutput();
+ DataSink sink = Manager.createDataSink(((Processor)player).getDataOutput(), dest);
+ player.start();
+ //do we know the output file's duration
+ StartRecording record = new StartRecording(sink);
+ record.run();

as well as the StartRecording thread. Don't they record in the same file
as the audio .... or am I missing something?

OK, forget what I said. I just figured it out, and it was silly of me
not to commit because otherwise there's no recording. Sorry. I am doing
so right now. I still changed one or two things, and one or two others
would need your attention:

* I renamed the start recording thread to - RecordInitiator
* Made sure that the method called in order to start the record is
start() and not run() (was there a reason why you didn't want this
executed in a separate thread?)
* Right now this works in a very mailbox oriented way. What I mean is
that all we do in the MediaService is say that a certain call would like
to write and read from custom locations (files) instead of the standard
ones (sound cart and screen).

Then suddenly the CallSessionImpl class somehow knows that it does not
have to record media until there's no more content in the outgoing data
source :).

For a while I was actually tempted to remove the record initiator thread
and have recording start right away, but decided not to do so now and
avoid messing something else up. So, it's your call. However, if you
decide to keep it, we'd definitely have to come up with a mechanism that
explicitly requires the mailbox plugin to specify the delay.

If we go for creating separate DataSrouce and DataSink interfaces in the
media service, for example, we could make the DataSource accept
listeners and notify them when it has reached the end of its content. At
this point the mailbox could call a method on the DataSink that would
allow it to start recording. This should be pretty straightforward to
implement too. Does it make sense to you?

Along the same lines, we should probably also explicitly specify, rather
than assuming it as default behavior, that we want the custom file data
source not to loop and that we want SIP Communicator to stop once it has
reached its end.

So, what do you think about all this?

Emil

···

So I guess that's it, I'd really appreciate it if you could make sure
that everything still works after my changes.

Actually... your changes in the IncomingCallTracker.run() method,
though they add greatly to readability, cause the program to infinite
loop ;p.

... well they are readable aren't they? It should be easy to find the
problem now :). Seriously, sorry for braking the code. I didn't have the
time to test it. Will be more careful next time.

I'll put the fix in along with some of the other little things you
mentioned in your message and send it in a new patch.

Cheers, and thank you for contributing!
Emil

No problem. I'm excited to see my changes merged into mainline!

Glad you are!

By the way, are you planning on writing some user interface that would
alert users when they have new messages, and allow them to play, store
and delete them?

Offering the possibility to record a new outgoing message through SIP
Communicator, as well as playing the existing one also seems like a
useful feature. Interested in taking this up?

Cheers
Emil

Ryan Ricard wrote:

Well, here it is. Attached is the code from my Summer of Code project
for the mailbox.

First, a few notes on the attachments:
-I think I did the diff syntax right, but let me know if I flubbed
something up.
-The binary files (one icon and one sound file) are included in a
separate archive so as not to ugly up the patch.

Also, a few notes on the content:
-The default outgoing message is me. Let me know if y'all need any
sort of licensing documentation or copyright-transferral
whachamahoozits.
-The Icon for the Mailbox's entry in the configuration window is taken
from the Tango Desktop Project. It seemed to fit and I am lazy (and no
artist!). I originally considered it a placeholder, but if we want to
use it It seems that we could. Their licensing conditions are CC
Attribution-Share Alike (available here:
http://creativecommons.org/licenses/by-sa/2.5/). I don't know how we'd
go about attributing them, so I will leave the decision as to how to
handle that (or make a new icon entirely) up to someone with more
know-how.
-There's a few limitations to the Mailbox that are probably worth
mentioning. I don't do any sort of compatibility checking on the
user's choice of an outgoing message, mostly because JMF is a bit of a
quagmire already in this area and we are planning a migration to FMJ
which might change the list of compatible formats even more. I highly
recommend testing a file in JMStudio before you use it as your
outgoing message
-Incoming messages are now just Audio. This one's high on my to-do list.

Other than that, things should pretty much work as expected. I'd
really like to continue contributing to the project even after the
Summer comes to a close, so please let me know if there are some
additional Mailbox features that are highly desirable.

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

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


#6

Hi!

One idea we have is a centrally stored contact list for sip. I miss this
feature in sipcommunicator now, but I would develop it as a plugin. I think
about exporting the contact list into xml (as it is stored locally) and
upload it to an ftp-server, and download it on startup.

Has anyone thought about such a feature and probably thought about some
reqirements?

Yours, thomas

···

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


#7

Our little question and answer is turning into quite an exchange!

Anyway, I don't have time right now to go through everything, so I'll
hit the high points.

I'm hoping to have a patch with the more straightforward fixes sent
sometime this weekend. Hopefully before we make the grand migration to
SVN-land.

The bigger stuff (new features for the mailbox, changes to the Media
Service, etc) will be coming... later. I'm very much intending on
continuing to contribute to SIP-Communicator in the future (y'all are
a pleasure to work with!), but classes are starting 'round these parts
so my contributions will be coming a little bit slower in the future.
So far all of your suggestions sound good, and we'll talk more
specifically about it once I get a chance to go over the details.

The 'pencils down' date for the SOC has passed, but let me know if
there's something specific I can do for y'all before the 31st.

Thanks again

···

On 8/28/07, Emil Ivov <emcho@sip-communicator.org> wrote:

Hi again Ryan,

(inline)

Emil Ivov wrote:
>>> -- I've removed the video handling code in here. Had you tested it? I
>>> have trouble understanding how it works, provided you hard set the file
>>> type to WAV, and weren't there any problems coming from the fact that
>>> you write to the same file from 2 different streams/threads?
>> I think what you are looking at is the code that used to handle the
>> video display (not my code). I think this code got replaced somewhere
>> along the line and I forgot to keep it out of the patch. sorry.
>
> I am talking about line 1693-1700 in the patch that look like this
>
>> + logger.info("starting recording to file: "+dataDestination);
>> + MediaLocator dest = new MediaLocator(dataDestination);
>> + DataSource ds = ((Processor)player).getDataOutput();
>> + DataSink sink = Manager.createDataSink(((Processor)player).getDataOutput(), dest);
>> + player.start();
>> + //do we know the output file's duration
>> + StartRecording record = new StartRecording(sink);
>> + record.run();
>
> as well as the StartRecording thread. Don't they record in the same file
> as the audio .... or am I missing something?

OK, forget what I said. I just figured it out, and it was silly of me
not to commit because otherwise there's no recording. Sorry. I am doing
so right now. I still changed one or two things, and one or two others
would need your attention:

* I renamed the start recording thread to - RecordInitiator
* Made sure that the method called in order to start the record is
start() and not run() (was there a reason why you didn't want this
executed in a separate thread?)
* Right now this works in a very mailbox oriented way. What I mean is
that all we do in the MediaService is say that a certain call would like
to write and read from custom locations (files) instead of the standard
ones (sound cart and screen).

Then suddenly the CallSessionImpl class somehow knows that it does not
have to record media until there's no more content in the outgoing data
source :).

For a while I was actually tempted to remove the record initiator thread
and have recording start right away, but decided not to do so now and
avoid messing something else up. So, it's your call. However, if you
decide to keep it, we'd definitely have to come up with a mechanism that
explicitly requires the mailbox plugin to specify the delay.

If we go for creating separate DataSrouce and DataSink interfaces in the
media service, for example, we could make the DataSource accept
listeners and notify them when it has reached the end of its content. At
this point the mailbox could call a method on the DataSink that would
allow it to start recording. This should be pretty straightforward to
implement too. Does it make sense to you?

Along the same lines, we should probably also explicitly specify, rather
than assuming it as default behavior, that we want the custom file data
source not to loop and that we want SIP Communicator to stop once it has
reached its end.

So, what do you think about all this?

Emil

>
>>> So I guess that's it, I'd really appreciate it if you could make sure
>>> that everything still works after my changes.
>> Actually... your changes in the IncomingCallTracker.run() method,
>> though they add greatly to readability, cause the program to infinite
>> loop ;p.
>
> ... well they are readable aren't they? It should be easy to find the
> problem now :). Seriously, sorry for braking the code. I didn't have the
> time to test it. Will be more careful next time.
>
>> I'll put the fix in along with some of the other little things you
>> mentioned in your message and send it in a new patch.
>>
>>
>>> Cheers, and thank you for contributing!
>>> Emil
>>>
>> No problem. I'm excited to see my changes merged into mainline!
>
> Glad you are!
>
> By the way, are you planning on writing some user interface that would
> alert users when they have new messages, and allow them to play, store
> and delete them?
>
> Offering the possibility to record a new outgoing message through SIP
> Communicator, as well as playing the existing one also seems like a
> useful feature. Interested in taking this up?
>
> Cheers
> Emil
>>> Ryan Ricard wrote:
>>>> Well, here it is. Attached is the code from my Summer of Code project
>>>> for the mailbox.
>>>>
>>>> First, a few notes on the attachments:
>>>> -I think I did the diff syntax right, but let me know if I flubbed
>>>> something up.
>>>> -The binary files (one icon and one sound file) are included in a
>>>> separate archive so as not to ugly up the patch.
>>>>
>>>> Also, a few notes on the content:
>>>> -The default outgoing message is me. Let me know if y'all need any
>>>> sort of licensing documentation or copyright-transferral
>>>> whachamahoozits.
>>>> -The Icon for the Mailbox's entry in the configuration window is taken
>>>> from the Tango Desktop Project. It seemed to fit and I am lazy (and no
>>>> artist!). I originally considered it a placeholder, but if we want to
>>>> use it It seems that we could. Their licensing conditions are CC
>>>> Attribution-Share Alike (available here:
>>>> http://creativecommons.org/licenses/by-sa/2.5/). I don't know how we'd
>>>> go about attributing them, so I will leave the decision as to how to
>>>> handle that (or make a new icon entirely) up to someone with more
>>>> know-how.
>>>> -There's a few limitations to the Mailbox that are probably worth
>>>> mentioning. I don't do any sort of compatibility checking on the
>>>> user's choice of an outgoing message, mostly because JMF is a bit of a
>>>> quagmire already in this area and we are planning a migration to FMJ
>>>> which might change the list of compatible formats even more. I highly
>>>> recommend testing a file in JMStudio before you use it as your
>>>> outgoing message
>>>> -Incoming messages are now just Audio. This one's high on my to-do list.
>>>>
>>>> Other than that, things should pretty much work as expected. I'd
>>>> really like to continue contributing to the project even after the
>>>> Summer comes to a close, so please let me know if there are some
>>>> additional Mailbox features that are highly desirable.
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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

--
Ryan Ricard
evilhecubus@gmail.com
ryan.ricard@student.utdallas.edu

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


#8

The contacts server should be accessible by LDAP. There are plenty of
Java LDAP client classes already existing (and tested). There are lots
of LDAP servers already running out there. There's lots more to
client/server transactions than just the data format, so XML alone isn't
a solution, and FTP isn't as good a protocol for these use cases as is
LDAP. LDAP is the precise solution for this. Let's not reinvent the
wheel for S-C.

···

On Tue, 2007-08-28 at 14:21 +0200, Thomas Hofer wrote:

Hi!

One idea we have is a centrally stored contact list for sip. I miss this
feature in sipcommunicator now, but I would develop it as a plugin. I think
about exporting the contact list into xml (as it is stored locally) and
upload it to an ftp-server, and download it on startup.

Has anyone thought about such a feature and probably thought about some
reqirements?

Yours, thomas

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


#9

Hi Thomas,

Thomas Hofer a �crit :

Hi!

One idea we have is a centrally stored contact list for sip. I miss this
feature in sipcommunicator now, but I would develop it as a plugin. I think
about exporting the contact list into xml (as it is stored locally) and
upload it to an ftp-server, and download it on startup.

Has anyone thought about such a feature and probably thought about some
reqirements?

Yep, I have tought about it sometimes ago, and I think it will be great to have such a feature.
The main "problem" I see is privacy concerns.

When someone has an account on some server, it is obvious that this server stores its personal data.
But what about storing them elsewhere ? If the user can have a "trusty server" it is OK.

Regards.

···

Yours, 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


#10

I will have a look at LDAP, thanks for your input.

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

I will have a look at LDAP, thanks for your input.

Thomas

···

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


#12

Hey Ryan,

Ryan Ricard wrote:

Our little question and answer is turning into quite an exchange!

Anyway, I don't have time right now to go through everything, so I'll
hit the high points.

I'm hoping to have a patch with the more straightforward fixes sent
sometime this weekend. Hopefully before we make the grand migration to
SVN-land.

It is not absolutely critical to have this before the SVN migration.
It'll be quite easy for you to do the patch against the new repository.
Basically you'd only have to copy you java files over those that you'll
retrieve through SVN.

The bigger stuff (new features for the mailbox, changes to the Media
Service, etc) will be coming... later. I'm very much intending on
continuing to contribute to SIP-Communicator in the future (y'all are
a pleasure to work with!),

Great! I am very glad to hear this!

but classes are starting 'round these parts
so my contributions will be coming a little bit slower in the future.
So far all of your suggestions sound good, and we'll talk more
specifically about it once I get a chance to go over the details.

Of course. There's no rush.

The 'pencils down' date for the SOC has passed, but let me know if
there's something specific I can do for y'all before the 31st.

I am sorry that I haven't made this clear earlier. You've submitted your
patch on time and it contained all we needed for your GSoC evaluation.
The comments that I've been sending since, were simply feedback that we
give to anyone who contributes code to SIP Communicator, so that they
know what we need in order to commit and activate their work. It is in
no way an obligation for you to act on these comments and if you do it
would be outside the context of GSoC and completely voluntary.

Cheers
Emil

···

Thanks again

On 8/28/07, Emil Ivov <emcho@sip-communicator.org> wrote:

Hi again Ryan,

(inline)

Emil Ivov wrote:

-- I've removed the video handling code in here. Had you tested it? I
have trouble understanding how it works, provided you hard set the file
type to WAV, and weren't there any problems coming from the fact that
you write to the same file from 2 different streams/threads?

I think what you are looking at is the code that used to handle the
video display (not my code). I think this code got replaced somewhere
along the line and I forgot to keep it out of the patch. sorry.

I am talking about line 1693-1700 in the patch that look like this

+ logger.info("starting recording to file: "+dataDestination);
+ MediaLocator dest = new MediaLocator(dataDestination);
+ DataSource ds = ((Processor)player).getDataOutput();
+ DataSink sink = Manager.createDataSink(((Processor)player).getDataOutput(), dest);
+ player.start();
+ //do we know the output file's duration
+ StartRecording record = new StartRecording(sink);
+ record.run();

as well as the StartRecording thread. Don't they record in the same file
as the audio .... or am I missing something?

OK, forget what I said. I just figured it out, and it was silly of me
not to commit because otherwise there's no recording. Sorry. I am doing
so right now. I still changed one or two things, and one or two others
would need your attention:

* I renamed the start recording thread to - RecordInitiator
* Made sure that the method called in order to start the record is
start() and not run() (was there a reason why you didn't want this
executed in a separate thread?)
* Right now this works in a very mailbox oriented way. What I mean is
that all we do in the MediaService is say that a certain call would like
to write and read from custom locations (files) instead of the standard
ones (sound cart and screen).

Then suddenly the CallSessionImpl class somehow knows that it does not
have to record media until there's no more content in the outgoing data
source :).

For a while I was actually tempted to remove the record initiator thread
and have recording start right away, but decided not to do so now and
avoid messing something else up. So, it's your call. However, if you
decide to keep it, we'd definitely have to come up with a mechanism that
explicitly requires the mailbox plugin to specify the delay.

If we go for creating separate DataSrouce and DataSink interfaces in the
media service, for example, we could make the DataSource accept
listeners and notify them when it has reached the end of its content. At
this point the mailbox could call a method on the DataSink that would
allow it to start recording. This should be pretty straightforward to
implement too. Does it make sense to you?

Along the same lines, we should probably also explicitly specify, rather
than assuming it as default behavior, that we want the custom file data
source not to loop and that we want SIP Communicator to stop once it has
reached its end.

So, what do you think about all this?

Emil

So I guess that's it, I'd really appreciate it if you could make sure
that everything still works after my changes.

Actually... your changes in the IncomingCallTracker.run() method,
though they add greatly to readability, cause the program to infinite
loop ;p.

... well they are readable aren't they? It should be easy to find the
problem now :). Seriously, sorry for braking the code. I didn't have the
time to test it. Will be more careful next time.

I'll put the fix in along with some of the other little things you
mentioned in your message and send it in a new patch.

Cheers, and thank you for contributing!
Emil

No problem. I'm excited to see my changes merged into mainline!

Glad you are!

By the way, are you planning on writing some user interface that would
alert users when they have new messages, and allow them to play, store
and delete them?

Offering the possibility to record a new outgoing message through SIP
Communicator, as well as playing the existing one also seems like a
useful feature. Interested in taking this up?

Cheers
Emil

Ryan Ricard wrote:

Well, here it is. Attached is the code from my Summer of Code project
for the mailbox.

First, a few notes on the attachments:
-I think I did the diff syntax right, but let me know if I flubbed
something up.
-The binary files (one icon and one sound file) are included in a
separate archive so as not to ugly up the patch.

Also, a few notes on the content:
-The default outgoing message is me. Let me know if y'all need any
sort of licensing documentation or copyright-transferral
whachamahoozits.
-The Icon for the Mailbox's entry in the configuration window is taken
from the Tango Desktop Project. It seemed to fit and I am lazy (and no
artist!). I originally considered it a placeholder, but if we want to
use it It seems that we could. Their licensing conditions are CC
Attribution-Share Alike (available here:
http://creativecommons.org/licenses/by-sa/2.5/). I don't know how we'd
go about attributing them, so I will leave the decision as to how to
handle that (or make a new icon entirely) up to someone with more
know-how.
-There's a few limitations to the Mailbox that are probably worth
mentioning. I don't do any sort of compatibility checking on the
user's choice of an outgoing message, mostly because JMF is a bit of a
quagmire already in this area and we are planning a migration to FMJ
which might change the list of compatible formats even more. I highly
recommend testing a file in JMStudio before you use it as your
outgoing message
-Incoming messages are now just Audio. This one's high on my to-do list.

Other than that, things should pretty much work as expected. I'd
really like to continue contributing to the project even after the
Summer comes to a close, so please let me know if there are some
additional Mailbox features that are highly desirable.

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

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


#13

Hi,

I totally agree with Matthew concerning the contact-list transfer. FTP wouldn't
be a good choice at all and wasn't really meant for that, whereas LDAP seems the
most obvious choice and probably the easiest to implement. What's more, we could
add support for central directory services afterwards. This way telephone
directories could be queried to find & contact people which aren't in the
contact list.

@Sympho: About the privacy concerns, using LDAP would enable us to
take advantage quite easily of TLS (ex-SSL, using StartTlsRequest) to secure the
transfer on the network. But if I understand correctly, what you're talking
about is avoiding to have private data leak out of a third-party server. I guess
that we could find a way to send the contact-list already crypted to the server,
but I don't know if it's really worth the pain (and it probably wouldn't be 100%
secure). Anyway, as you suggested, somebody could always host his own LDAP
server if his contact list is so sensitive ;).

Cheers,
Chris.

Selon Sympho <symphorien.wanko-tchuente@ulp.u-strasbg.fr>:

···

Hi Thomas,

Thomas Hofer a �crit :
> Hi!
>
> One idea we have is a centrally stored contact list for sip. I miss this
> feature in sipcommunicator now, but I would develop it as a plugin. I think
> about exporting the contact list into xml (as it is stored locally) and
> upload it to an ftp-server, and download it on startup.
>
> Has anyone thought about such a feature and probably thought about some
> reqirements?
>
>
Yep, I have tought about it sometimes ago, and I think it will be great
to have such a feature.
The main "problem" I see is privacy concerns.

When someone has an account on some server, it is obvious that this
server stores its personal data.
But what about storing them elsewhere ? If the user can have a "trusty
server" it is OK.

Regards.
> Yours, 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

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


#14

What I thought about is do add it as normal ftp service. You can use ANY
ftp-server you want, thus even your own one. I think this is enough for
nearly everybody. People trusting the world can use any (free) ftp server,
people who care about their privacy can store the data on their own server
or servers which they trust.
Thomas

···

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


#15

Thanks Emil

I am sorry that I haven't made this clear earlier. You've submitted your
patch on time and it contained all we needed for your GSoC evaluation.
The comments that I've been sending since, were simply feedback that we
give to anyone who contributes code to SIP Communicator, so that they
know what we need in order to commit and activate their work. It is in
no way an obligation for you to act on these comments and if you do it
would be outside the context of GSoC and completely voluntary.

That's what I assumed. Just making sure.

···

On 8/30/07, Emil Ivov <emcho@sip-communicator.org> wrote:

Hey Ryan,

Ryan Ricard wrote:
> Our little question and answer is turning into quite an exchange!
>
> Anyway, I don't have time right now to go through everything, so I'll
> hit the high points.
>
> I'm hoping to have a patch with the more straightforward fixes sent
> sometime this weekend. Hopefully before we make the grand migration to
> SVN-land.

It is not absolutely critical to have this before the SVN migration.
It'll be quite easy for you to do the patch against the new repository.
Basically you'd only have to copy you java files over those that you'll
retrieve through SVN.

> The bigger stuff (new features for the mailbox, changes to the Media
> Service, etc) will be coming... later. I'm very much intending on
> continuing to contribute to SIP-Communicator in the future (y'all are
> a pleasure to work with!),

Great! I am very glad to hear this!

> but classes are starting 'round these parts
> so my contributions will be coming a little bit slower in the future.
> So far all of your suggestions sound good, and we'll talk more
> specifically about it once I get a chance to go over the details.

Of course. There's no rush.

> The 'pencils down' date for the SOC has passed, but let me know if
> there's something specific I can do for y'all before the 31st.

I am sorry that I haven't made this clear earlier. You've submitted your
patch on time and it contained all we needed for your GSoC evaluation.
The comments that I've been sending since, were simply feedback that we
give to anyone who contributes code to SIP Communicator, so that they
know what we need in order to commit and activate their work. It is in
no way an obligation for you to act on these comments and if you do it
would be outside the context of GSoC and completely voluntary.

Cheers
Emil

>
> Thanks again
>
> On 8/28/07, Emil Ivov <emcho@sip-communicator.org> wrote:
>> Hi again Ryan,
>>
>> (inline)
>>
>> Emil Ivov wrote:
>>>>> -- I've removed the video handling code in here. Had you tested it? I
>>>>> have trouble understanding how it works, provided you hard set the file
>>>>> type to WAV, and weren't there any problems coming from the fact that
>>>>> you write to the same file from 2 different streams/threads?
>>>> I think what you are looking at is the code that used to handle the
>>>> video display (not my code). I think this code got replaced somewhere
>>>> along the line and I forgot to keep it out of the patch. sorry.
>>> I am talking about line 1693-1700 in the patch that look like this
>>>
>>>> + logger.info("starting recording to file: "+dataDestination);
>>>> + MediaLocator dest = new MediaLocator(dataDestination);
>>>> + DataSource ds = ((Processor)player).getDataOutput();
>>>> + DataSink sink = Manager.createDataSink(((Processor)player).getDataOutput(), dest);
>>>> + player.start();
>>>> + //do we know the output file's duration
>>>> + StartRecording record = new StartRecording(sink);
>>>> + record.run();
>>> as well as the StartRecording thread. Don't they record in the same file
>>> as the audio .... or am I missing something?
>> OK, forget what I said. I just figured it out, and it was silly of me
>> not to commit because otherwise there's no recording. Sorry. I am doing
>> so right now. I still changed one or two things, and one or two others
>> would need your attention:
>>
>> * I renamed the start recording thread to - RecordInitiator
>> * Made sure that the method called in order to start the record is
>> start() and not run() (was there a reason why you didn't want this
>> executed in a separate thread?)
>> * Right now this works in a very mailbox oriented way. What I mean is
>> that all we do in the MediaService is say that a certain call would like
>> to write and read from custom locations (files) instead of the standard
>> ones (sound cart and screen).
>>
>> Then suddenly the CallSessionImpl class somehow knows that it does not
>> have to record media until there's no more content in the outgoing data
>> source :).
>>
>> For a while I was actually tempted to remove the record initiator thread
>> and have recording start right away, but decided not to do so now and
>> avoid messing something else up. So, it's your call. However, if you
>> decide to keep it, we'd definitely have to come up with a mechanism that
>> explicitly requires the mailbox plugin to specify the delay.
>>
>> If we go for creating separate DataSrouce and DataSink interfaces in the
>> media service, for example, we could make the DataSource accept
>> listeners and notify them when it has reached the end of its content. At
>> this point the mailbox could call a method on the DataSink that would
>> allow it to start recording. This should be pretty straightforward to
>> implement too. Does it make sense to you?
>>
>> Along the same lines, we should probably also explicitly specify, rather
>> than assuming it as default behavior, that we want the custom file data
>> source not to loop and that we want SIP Communicator to stop once it has
>> reached its end.
>>
>> So, what do you think about all this?
>>
>> Emil
>>
>>
>>
>>
>>>>> So I guess that's it, I'd really appreciate it if you could make sure
>>>>> that everything still works after my changes.
>>>> Actually... your changes in the IncomingCallTracker.run() method,
>>>> though they add greatly to readability, cause the program to infinite
>>>> loop ;p.
>>> ... well they are readable aren't they? It should be easy to find the
>>> problem now :). Seriously, sorry for braking the code. I didn't have the
>>> time to test it. Will be more careful next time.
>>>
>>>> I'll put the fix in along with some of the other little things you
>>>> mentioned in your message and send it in a new patch.
>>>>
>>>>
>>>>> Cheers, and thank you for contributing!
>>>>> Emil
>>>>>
>>>> No problem. I'm excited to see my changes merged into mainline!
>>> Glad you are!
>>>
>>> By the way, are you planning on writing some user interface that would
>>> alert users when they have new messages, and allow them to play, store
>>> and delete them?
>>>
>>> Offering the possibility to record a new outgoing message through SIP
>>> Communicator, as well as playing the existing one also seems like a
>>> useful feature. Interested in taking this up?
>>>
>>> Cheers
>>> Emil
>>>>> Ryan Ricard wrote:
>>>>>> Well, here it is. Attached is the code from my Summer of Code project
>>>>>> for the mailbox.
>>>>>>
>>>>>> First, a few notes on the attachments:
>>>>>> -I think I did the diff syntax right, but let me know if I flubbed
>>>>>> something up.
>>>>>> -The binary files (one icon and one sound file) are included in a
>>>>>> separate archive so as not to ugly up the patch.
>>>>>>
>>>>>> Also, a few notes on the content:
>>>>>> -The default outgoing message is me. Let me know if y'all need any
>>>>>> sort of licensing documentation or copyright-transferral
>>>>>> whachamahoozits.
>>>>>> -The Icon for the Mailbox's entry in the configuration window is taken
>>>>>> from the Tango Desktop Project. It seemed to fit and I am lazy (and no
>>>>>> artist!). I originally considered it a placeholder, but if we want to
>>>>>> use it It seems that we could. Their licensing conditions are CC
>>>>>> Attribution-Share Alike (available here:
>>>>>> http://creativecommons.org/licenses/by-sa/2.5/). I don't know how we'd
>>>>>> go about attributing them, so I will leave the decision as to how to
>>>>>> handle that (or make a new icon entirely) up to someone with more
>>>>>> know-how.
>>>>>> -There's a few limitations to the Mailbox that are probably worth
>>>>>> mentioning. I don't do any sort of compatibility checking on the
>>>>>> user's choice of an outgoing message, mostly because JMF is a bit of a
>>>>>> quagmire already in this area and we are planning a migration to FMJ
>>>>>> which might change the list of compatible formats even more. I highly
>>>>>> recommend testing a file in JMStudio before you use it as your
>>>>>> outgoing message
>>>>>> -Incoming messages are now just Audio. This one's high on my to-do list.
>>>>>>
>>>>>> Other than that, things should pretty much work as expected. I'd
>>>>>> really like to continue contributing to the project even after the
>>>>>> Summer comes to a close, so please let me know if there are some
>>>>>> additional Mailbox features that are highly desirable.
>>>>>>
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------------
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> 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

--
Ryan Ricard
evilhecubus@gmail.com
ryan.ricard@student.utdallas.edu

---------------------------------------------------------------------
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,
   
  Google database could be another solution.
  Check out API and you see !
   
  Dennis
   
Chris <sipcom@cyberspace7.net> a �crit :
  Hi,

I totally agree with Matthew concerning the contact-list transfer. FTP wouldn't
be a good choice at all and wasn't really meant for that, whereas LDAP seems the
most obvious choice and probably the easiest to implement. What's more, we could
add support for central directory services afterwards. This way telephone
directories could be queried to find & contact people which aren't in the
contact list.

@Sympho: About the privacy concerns, using LDAP would enable us to
take advantage quite easily of TLS (ex-SSL, using StartTlsRequest) to secure the
transfer on the network. But if I understand correctly, what you're talking
about is avoiding to have private data leak out of a third-party server. I guess
that we could find a way to send the contact-list already crypted to the server,
but I don't know if it's really worth the pain (and it probably wouldn't be 100%
secure). Anyway, as you suggested, somebody could always host his own LDAP
server if his contact list is so sensitive ;).

Cheers,
Chris.

Selon Sympho :

···

Hi Thomas,

Thomas Hofer a �crit :
> Hi!
>
> One idea we have is a centrally stored contact list for sip. I miss this
> feature in sipcommunicator now, but I would develop it as a plugin. I think
> about exporting the contact list into xml (as it is stored locally) and
> upload it to an ftp-server, and download it on startup.
>
> Has anyone thought about such a feature and probably thought about some
> reqirements?
>
>
Yep, I have tought about it sometimes ago, and I think it will be great
to have such a feature.
The main "problem" I see is privacy concerns.

When someone has an account on some server, it is obvious that this
server stores its personal data.
But what about storing them elsewhere ? If the user can have a "trusty
server" it is OK.

Regards.
> Yours, 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

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

---------------------------------
Ne gardez plus qu'une seule adresse mail ! Copiez vos mails vers Yahoo! Mail


#17

Hi everyone,

I agree with what Matthew said about LDAP being the perfect solution.

However, I think that an eventual implementation of a file-based server storage agent (working over FTP/SFTP/HTTP/...) can also be useful. I'm saying "agent" because I think that the same concept may be reused - one may wish to have server stored message history, photos, etc. Of course, there are many issues that have to be resolved, like encrypting everything that goes to the server, etc. I think of a service that receives a URL (like ftp://freestorage....../scaccounts/) and downloads all information relative to the current user from that location. Furthermore, if at some point someone tells the same service - "hey, I'd really appreciate if you can keep the file 'sip-communicator/specialsettings.xml'", the service would handle the request by itself (uploading the encrypted file with eventually adding some metainformation, ... AND doing this each time the file changes).

So, just to summarize - having a purely file-based approach would bring in some great flexibility (once implemented for FTP it would be relatively easy to add support for other protocols, with the only difference being the protocol-specific code) BUT is not a very clean solution (i.e. to achieve a true asynchronous contact list loading one has to download the file + parse the XML).

In all cases I don't think that this is going to be the major problem. LDAP is certainly going to provide some nice querying abilities and a "true" asynchronous data loading (and is THE way to do this thing), but it's not going to address the main issue - merging the incoming Metacontacts.

In my view there are two approaches to this problem (which do not depend on the underlaying server storing mechanism) :

1) (SYNC) Download the data BEFORE any other service is launched (or just tell all other services to wait quietly and do nothing) and then merge the local information with the server-side information. After the data is merged, all services are told to resume their execution.
This solution may significantly increase the load time of the application (the client will have to wait for a connection timeout if for example the remote server is down), which I think is going to seriously degrade the user experience. Additionally, I think that there will always be some cases in which one would have to perform asynchronous contact merging (thus falling in the second category).

2) (ASYNC) Download the data in parallel to other services that are being loaded. That means merging Metacontacts on the fly.
In my opinion this is a case that should be addressed. Currently SC merges the locally contained contact information with incoming protocol specific server-stored contacts, but I don't know if the same mechanism is going to work right away when Metacontacts are going to start flying in. Can anyone tell the rules upon which contacts are currently merged and if this is going to work for Metacontacts?

The best thing would be to allow users to store their data on different kinds of servers but given the limited resources we have I would also go with the LDAP solution.

Regards,
Alex

···

Le 28 août 07 à 15:52, Chris a écrit :

Hi,

I totally agree with Matthew concerning the contact-list transfer. FTP wouldn't
be a good choice at all and wasn't really meant for that, whereas LDAP seems the
most obvious choice and probably the easiest to implement. What's more, we could
add support for central directory services afterwards. This way telephone
directories could be queried to find & contact people which aren't in the
contact list.

@Sympho: About the privacy concerns, using LDAP would enable us to
take advantage quite easily of TLS (ex-SSL, using StartTlsRequest) to secure the
transfer on the network. But if I understand correctly, what you're talking
about is avoiding to have private data leak out of a third-party server. I guess
that we could find a way to send the contact-list already crypted to the server,
but I don't know if it's really worth the pain (and it probably wouldn't be 100%
secure). Anyway, as you suggested, somebody could always host his own LDAP
server if his contact list is so sensitive ;).

Cheers,
Chris.

Selon Sympho <symphorien.wanko-tchuente@ulp.u-strasbg.fr>:

Hi Thomas,

Thomas Hofer a écrit :

Hi!

One idea we have is a centrally stored contact list for sip. I miss this
feature in sipcommunicator now, but I would develop it as a plugin. I think
about exporting the contact list into xml (as it is stored locally) and
upload it to an ftp-server, and download it on startup.

Has anyone thought about such a feature and probably thought about some
reqirements?

Yep, I have tought about it sometimes ago, and I think it will be great
to have such a feature.
The main "problem" I see is privacy concerns.

When someone has an account on some server, it is obvious that this
server stores its personal data.
But what about storing them elsewhere ? If the user can have a "trusty
server" it is OK.

Regards.

Yours, 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

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


#18

Replacing the *open standard* LDAP with dependency on a *single vendor*
*proprietary* protocol is a bad solution. How many orgs are running a
Google contact DB on their LAN/intranet? Vs how many running LDAP? How
much existing Google API SW is there for the many different solutions,
vs the huge LDAP community's?

  Of course the best S-C architecture would make the contacts network
protocol a plugin with a consistent internal API. But by far the most
productive default plugin would be LDAP.

···

On Tue, 2007-08-28 at 16:18 +0200, D. Lazreg wrote:

Hi,

Google database could be another solution.
Check out API and you see !

Dennis

Chris <sipcom@cyberspace7.net> a écrit :
        Hi,
        
        I totally agree with Matthew concerning the contact-list
        transfer. FTP wouldn't
        be a good choice at all and wasn't really meant for that,
        whereas LDAP seems the
        most obvious choice and probably the easiest to implement.
        What's more, we could
        add support for central directory services afterwards. This
        way telephone
        directories could be queried to find & contact people which
        aren't in the
        contact list.
        
        @Sympho: About the privacy concerns, using LDAP would enable
        us to
        take advantage quite easily of TLS (ex-SSL, using
        StartTlsRequest) to secure the
        transfer on the network. But if I understand correctly, what
        you're talking
        about is avoiding to have private data leak out of a
        third-party server. I guess
        that we could find a way to send the contact-list already
        crypted to the server,
        but I don't know if it's really worth the pain (and it
        probably wouldn't be 100%
        secure). Anyway, as you suggested, somebody could always host
        his own LDAP
        server if his contact list is so sensitive ;).
        
        Cheers,
        Chris.
        
        Selon Sympho :
        
        > Hi Thomas,
        >
        > Thomas Hofer a écrit :
        > > Hi!
        > >
        > > One idea we have is a centrally stored contact list for
        sip. I miss this
        > > feature in sipcommunicator now, but I would develop it as
        a plugin. I think
        > > about exporting the contact list into xml (as it is stored
        locally) and
        > > upload it to an ftp-server, and download it on startup.
        > >
        > > Has anyone thought about such a feature and probably
        thought about some
        > > reqirements?
        > >
        > >
        > Yep, I have tought about it sometimes ago, and I think it
        will be great
        > to have such a feature.
        > The main "problem" I see is privacy concerns.
        >
        > When someone has an account on some server, it is obvious
        that this
        > server stores its personal data.
        > But what about storing them elsewhere ? If the user can have
        a "trusty
        > server" it is OK.
        >
        > Regards.
        > > Yours, 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
        >
        >
        
        ---------------------------------------------------------------------
        To unsubscribe, e-mail:
        dev-unsubscribe@sip-communicator.dev.java.net
        For additional commands, e-mail:
        dev-help@sip-communicator.dev.java.net
        
______________________________________________________________________
Ne gardez plus qu'une seule adresse mail ! Copiez vos mails vers
Yahoo! Mail

--

(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


#19

Hi,
I haven't worked with Google Base before but I feel a couple of
problems with it:
  * some people don't like trusting their stuff to Google. And that
includes SIP contacts.
  * from what I could grasp in a 20 seconds scan of the Google Base
pages, all the data in there is publicly searchable which might add
further privacy concerns.
I would go for LDAP as Matthew suggestes as it's best fit for such
purpose and in extremis someone can run it's own server :stuck_out_tongue: (I know, it
has already been said)

All the best,
Mihai

···

On 8/28/07, D. Lazreg <dlazreg@yahoo.fr> wrote:

Hi,

Google database could be another solution.
Check out API and you see !

Dennis

Chris <sipcom@cyberspace7.net> a écrit :
Hi,

I totally agree with Matthew concerning the contact-list transfer. FTP
wouldn't
be a good choice at all and wasn't really meant for that, whereas LDAP seems
the
most obvious choice and probably the easiest to implement. What's more, we
could
add support for central directory services afterwards. This way telephone
directories could be queried to find & contact people which aren't in the
contact list.

@Sympho: About the privacy concerns, using LDAP would enable us to
take advantage quite easily of TLS (ex-SSL, using StartTlsRequest) to secure
the
transfer on the network. But if I understand correctly, what you're talking
about is avoiding to have private data leak out of a third-party server. I
guess
that we could find a way to send the contact-list already crypted to the
server,
but I don't know if it's really worth the pain (and it probably wouldn't be
100%
secure). Anyway, as you suggested, somebody could always host his own LDAP
server if his contact list is so sensitive ;).

Cheers,
Chris.

Selon Sympho :

> Hi Thomas,
>
> Thomas Hofer a écrit :
> > Hi!
> >
> > One idea we have is a centrally stored contact list for sip. I miss this
> > feature in sipcommunicator now, but I would develop it as a plugin. I
think
> > about exporting the contact list into xml (as it is stored locally) and
> > upload it to an ftp-server, and download it on startup.
> >
> > Has anyone thought about such a feature and probably thought about some
> > reqirements?
> >
> >
> Yep, I have tought about it sometimes ago, and I think it will be great
> to have such a feature.
> The main "problem" I see is privacy concerns.
>
> When someone has an account on some server, it is obvious that this
> server stores its personal data.
> But what about storing them elsewhere ? If the user can have a "trusty
> server" it is OK.
>
> Regards.
> > Yours, thomas


#20

Hey all,

I really like the idea about storing the meta contact list somewhere
over the Internet so that you don't have to remerge all contacts every
time you install SIP Communicator.

Of course the plugin would definitely need to take care of security and
make sure that the data is encrypted while transferred. SFTP and TLS for
LDAP would probably suffice.

As far as privacy goes, I don't think that we need to worry about it
that much. It is up to the user to choose where they store data so we
could say that they could come up with a location that they trust. Of
course, if we decide to offer a default server, we'd have to consider
the issue. Encrypting data would probably be a good solution and it
could always be added at a later stage.

Now, concerning fine grained storage (e.g. LDAP, Google Base) vs.
storing the whole contact list file (e.g. SFTP), I am not sure which one
would be better. Both have pros and cons and the choice would mostly
depend on how much effort you are willing to put in.

Here's what I am thinking of:

* Probably the easiest way to go would be to make sure that the
contactlist.xml is retrieved lolcally before MclStorageManager tries to
load it, and then upload it back on the server after it has been shut
down. This, however, means that if SIP Communicator hangs or is killed
before the upload has been completed any changes during the last session
would be lost.

Implementing this does not even have to directly interact with the
MetaContactListService. I like the Alex's suggestion of modifying the
FileAccess service and adding this as a remote backup option.

This would avoid having to deal with the synchronization problems that
Alex mentioned since the MetaContactListService implementation would
continue handling them as it currently is.

* If, you are prepared to spend more time hacking at this then you could
go for the LDAP/Google Base solution. In this case you'd have to
consider replacing or extending the MclStorageManager class. Normally
this class would rewrite the contactlist.xml file every time the meta
contact list changes. You'd have to make sure that instead or in
addition to doing this you execute LDAP/GBase operations.

Right now we assume that the meta contact list is always a step behind
the protocols concerning the exact content of a protocol specific
contact list, so if we notice a discrepancy (e.g. a contact in a
protocol provider appears in a different group from the one that the
MetaContactList currently believes it in) it would readjust its contents
so that it matches that of the protocol provider assuming that the user
has made the changes elsewhere (e.g. using another IM client). I'd
suggest you stick to this logic in order to avoid behaviour that would
annoy most users.

Really hope this helps - I'd love the feature!

Cheers
Emil

Alexander Pelov wrote:

···

Hi everyone,

I agree with what Matthew said about LDAP being the perfect solution.

However, I think that an eventual implementation of a file-based
server storage agent (working over FTP/SFTP/HTTP/...) can also be
useful. I'm saying "agent" because I think that the same concept may
be reused - one may wish to have server stored message history,
photos, etc. Of course, there are many issues that have to be
resolved, like encrypting everything that goes to the server, etc. I
think of a service that receives a URL (like ftp://freestorage....../
scaccounts/) and downloads all information relative to the current
user from that location. Furthermore, if at some point someone tells
the same service - "hey, I'd really appreciate if you can keep the
file 'sip-communicator/specialsettings.xml'", the service would
handle the request by itself (uploading the encrypted file with
eventually adding some metainformation, ... AND doing this each time
the file changes).

So, just to summarize - having a purely file-based approach would
bring in some great flexibility (once implemented for FTP it would be
relatively easy to add support for other protocols, with the only
difference being the protocol-specific code) BUT is not a very clean
solution (i.e. to achieve a true asynchronous contact list loading
one has to download the file + parse the XML).

In all cases I don't think that this is going to be the major
problem. LDAP is certainly going to provide some nice querying
abilities and a "true" asynchronous data loading (and is THE way to
do this thing), but it's not going to address the main issue -
merging the incoming Metacontacts.

In my view there are two approaches to this problem (which do not
depend on the underlaying server storing mechanism) :

1) (SYNC) Download the data BEFORE any other service is launched (or
just tell all other services to wait quietly and do nothing) and then
merge the local information with the server-side information. After
the data is merged, all services are told to resume their execution.
This solution may significantly increase the load time of the
application (the client will have to wait for a connection timeout if
for example the remote server is down), which I think is going to
seriously degrade the user experience. Additionally, I think that
there will always be some cases in which one would have to perform
asynchronous contact merging (thus falling in the second category).

2) (ASYNC) Download the data in parallel to other services that are
being loaded. That means merging Metacontacts on the fly.
In my opinion this is a case that should be addressed. Currently SC
merges the locally contained contact information with incoming
protocol specific server-stored contacts, but I don't know if the
same mechanism is going to work right away when Metacontacts are
going to start flying in. Can anyone tell the rules upon which
contacts are currently merged and if this is going to work for
Metacontacts?

The best thing would be to allow users to store their data on
different kinds of servers but given the limited resources we have I
would also go with the LDAP solution.

Regards,
Alex

Le 28 ao�t 07 � 15:52, Chris a �crit :

Hi,

I totally agree with Matthew concerning the contact-list transfer.
FTP wouldn't
be a good choice at all and wasn't really meant for that, whereas
LDAP seems the
most obvious choice and probably the easiest to implement. What's
more, we could
add support for central directory services afterwards. This way
telephone
directories could be queried to find & contact people which aren't
in the
contact list.

@Sympho: About the privacy concerns, using LDAP would enable us to
take advantage quite easily of TLS (ex-SSL, using StartTlsRequest)
to secure the
transfer on the network. But if I understand correctly, what you're
talking
about is avoiding to have private data leak out of a third-party
server. I guess
that we could find a way to send the contact-list already crypted
to the server,
but I don't know if it's really worth the pain (and it probably
wouldn't be 100%
secure). Anyway, as you suggested, somebody could always host his
own LDAP
server if his contact list is so sensitive ;).

Cheers,
Chris.

Selon Sympho <symphorien.wanko-tchuente@ulp.u-strasbg.fr>:

Hi Thomas,

Thomas Hofer a �crit :

Hi!

One idea we have is a centrally stored contact list for sip. I
miss this
feature in sipcommunicator now, but I would develop it as a
plugin. I think
about exporting the contact list into xml (as it is stored
locally) and
upload it to an ftp-server, and download it on startup.

Has anyone thought about such a feature and probably thought
about some
reqirements?

Yep, I have tought about it sometimes ago, and I think it will be
great
to have such a feature.
The main "problem" I see is privacy concerns.

When someone has an account on some server, it is obvious that this
server stores its personal data.
But what about storing them elsewhere ? If the user can have a
"trusty
server" it is OK.

Regards.

Yours, 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

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