Thursday, June 28, 2007

It works better!

Based on a conversation with Emil today, I changed the way that the DataSource is switched over to a file. Instead of changing the default data source, I have sip-communicator make a new instance of MediaControl, instantiate it with the outgoing message file, and place the mapping of that particular mediacontrol to that particular call in a hashmap. Once the call ends, said mapping is removed. In this way, calls that are picked up normally get the usual DataSource while calls that are picked up by the mailbox get the outgoing message.

And to top it all off, it actually works!

I suppose that My next goal is to get the input from the remote caller redirected to a file and save the incoming message. Wish me luck.

Wednesday, June 27, 2007

It Works!

I got an outgoing message to play today!

So what was that insidious bug, lurking around in my code, preventing the file from playing?

I forgot to tell the Mailbox to quit waiting after it starts to connect the call. It just kept looping, re-starting the call every 10 seconds.

D'oh.


Right away I noticed that I forgot to set SIP-Communicator's data source back to default after the call ends, so the next call gets connected to the outgoing message even if you click the "connect" button. so fixing that is my next step.

Luckily, the CallListener interface (that Mailbox already implements) has a CallEnded method that will be called when a call ends. So I will insert code there that will check to see if the data source is set to default and re-initialize it if it is not.

Easy, right? Ah, the hubris of optimism.

Monday, June 25, 2007

Datasources in the mist

This morning I observed how sip-communicator plays out from a file while in its natural habitat. I knew that sip-communicator had such functionality from looking at the code, but as until a recent conversation with Emil I hadn't known how to turn it on. turns out that is as easy as adding the following little tidbit to sip-communicator.xml:

(NOTE: Blogger ate my XML, so I replaced the angle brackets with square brackets. You get the idea)

[media]
[debug_data_source_url value="file:///home/ryan/Desktop/lostinspace.mov"/]
[/debug_data_source_url]
[/media]
[/impl]

notice that the tag is nested within the tag. The namespace resolution for the system properties follows the structure of the xml document.
Some.System.Property.Here corresponds to [some][system][property][here value="stuff"/][/here][/property][/system][/some]



I also installed JMStudio so that I can be sure that if a file doesn't play in the future that it is my fault and not JMF's

Thursday, June 21, 2007

Easier than I thought

I found a much easier way to load up two instances of sip communicator with different config files (and therefore different sip accounts).

It turns out that the first place that sip communicator looks for a configuration file is the current directory, IE the directory from which ant is called. So I just have a separate sip-communicator.xml file in my sc-avmailbox directory.

I'm not going to mention the system that I had in place earlier. Such Kludges ought not be discussed in mixed company.

Wednesday, June 20, 2007

more little issues

spent the morning tracking down some new problems with importing sip-communicator's build.xml. I want to say that I've got it all figured out and I can now focus all my energies on getting the mailbox to work properly, but I've said that before ;)

Anyway, at least I know that my repository has everything it needs, in case I need to do a spontaneous reformat/reinstall like I did yesterday. Long story short, backups are good.

Tuesday, June 19, 2007

I feel like I contributed something

My patch got accepted and I can now build sip-communicator and sc-avmailbox using the cvs copy.

I figured out why files were mysteriously missing from my svn repository today after I did a checkout. It turns out that copying over backed-up files into a blank repository and including the ".svn" folder will make svn think that files are in the repository when they are not. I think I've got it all sorted out though.

Thursday, June 14, 2007

it works!

I sent in what is (hopefully) my first working patch to the dev mailing list today.

After tracking down a few nit-picky errors, I've got my project set up so that I can update sip-communicator from cvs, update sc-avmailbox from svn, and nothing breaks!

yet.

check back in a few days and see if I'm so optimistic.

Anyway, back to work on getting an outgoing message to play. Last I checked the call to manager.createDataSource was coming back null. Since this method usually throws an exception when it messes up (IE the NoDataSourceException described earlier), I'm not even sure what that means.

Tuesday, June 12, 2007

Modifying build.xml to be import-able

My first hurdle in setting up the parallel repositories for my code and sip-communicator is the fact that the sip-communicator build.xml file does not refer to itself in a way that makes it importable.

I'd go on and explain, but really the apache documentation on the import function does a much better job. Basically I need to change the file so that input files are taken from /path/to/where/the/buildfile/is/src, but output files go to /path/to/where/the/buildfile/isrun/from/sc-bundles

Basically this post was written to give me a break in the find- and replacing.

:)

just realized that the blog is quite outdated

all that business I was talking about before, forget it.

Here is the new new strategy for getting my code to work alongside sip-communicator:

-have both projects stored under /home/ryan/sip, side by side. My code is in /home/ryan/sip/sc-avmailbox and the sip-communicator sources are in /home/ryan/sip/sip-communicator.

-have the build.xml in sc-avmailbox import the build.xml in sip-communicator, redefining targets as necessary to build the files that I've added to sip-comm

-using some ant trickery, make sure that for any files in sip-comm that I modified, my version is built instead of the sip-comm version.

After a conversation with emil, I think that I'm ready to get all the little details in this strategy ironed out. Hopefully after I do so I'll be able to make a template that other people in a similar situation (having to develop an addon while staying current with main) can follow.

Monday, June 4, 2007

late breaking news

svn is a working, building, complete copy of sip-communicator.

project website looks like it should.

I feel so fresh, so clean.

Anyway, back to work.

a little progress on both fronts

on rebooting the repository:

Wow, was that a mess. But once I figured out that doing a "cp -R *" on a working copy retains a bunch of '.svn' files that mess up my attempts at cleaning out the repository and starting over. Duh. Ah well, after a bit of wasted time I think I'm waiting through the one great file transfer that will give me a real repository. Let's hope.

I also figured out that the project's website is copied in the www folder, so the website is currently blank. Should be able to fix that by the end of the night.

On the code:
I fixed all the compiler/design level problems (I think), but I get a NoDataSourceException when I try to set up a sendstream on the outgoing message file. More on that as I get to the bottom of it.

Saturday, June 2, 2007

fork this

I'm trying to see if my modifications to the MediaService class/interface to handle incoming calls worked, and I've got all sorts of build errors in different parts of the project. My original intent in setting up a build environment was to have an update-able copy of SIP-Communicator alongside any copies of files I'd need to modify in a separate folder connected to my svn repository.

That was a bad idea.

Later tonight I am going to make a checkout of sip-communicator, move the necessary files over to my project folder, and do a reboot of my svn repository. I'll worry about merging back into mainline at a later date. Better than worrying about it every time I want to do a build.