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 <emchosip-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-unsubscribesip-communicator.dev.java.net
> >>>>>> For additional commands,
e-mail: dev-helpsip-communicator.dev.java.net
> >>>>>
------------------------------------------------------------
---------
> >>>>> To unsubscribe, e-mail:
dev-unsubscribesip-communicator.dev.java.net
> >>>>> For additional commands, e-mail:
dev-helpsip-communicator.dev.java.net
> >>>>>
> >>>>>
> >>>
------------------------------------------------------------
---------
> >>> To unsubscribe, e-mail:
dev-unsubscribesip-communicator.dev.java.net
> >>> For additional commands, e-mail:
dev-helpsip-communicator.dev.java.net
> >>>
> >>>
> >>
------------------------------------------------------------
---------
> >> To unsubscribe, e-mail: dev-unsubscribesip-communicator.dev.java.net
> >> For additional commands, e-mail: dev-helpsip-communicator.dev.java.net
> >>
> >>
> >
> >
>
>
------------------------------------------------------------
---------
> To unsubscribe, e-mail: dev-unsubscribesip-communicator.dev.java.net
> For additional commands, e-mail: dev-helpsip-communicator.dev.java.net
>
>
--
Ryan Ricard
evilhecubusgmail.com
ryan.ricardstudent.utdallas.edu
------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesip-communicator.dev.java.net
For additional commands, e-mail: dev-helpsip-communicator.dev.java.net
|