Week 12

Week 12 was the last full week for UCOSP, and the last full week of classes. Needless to say, things are busy. Officially I still have two more days of classes, which means I likewise have two more days to finish up and close my final PR!

What I Worked On

After receiving some feedback on the API Configuration implementation, I set to making some needed additions and changes:

- Refactored the configuration controller code into its own subpackage with a module just for the endpoints, and another to contain all of the associated helper methods.

- Implemented the endpoint for listing existing plugin instances from the plugin.conf file

- Implemented the creation of unique plugin instances using UUIDs

- Numerous style changes and comments

- Unit tests for the newly implemented endpoints

I also spent some time testing all of the endpoints using a chrome extension for sending REST Client requests (Advanced REST Client): 

https://chrome.google.com/webstore/detail/advanced-rest-client/hgmloofddffdnphfgcellkdfbfbjeloo

It was very cool to see all of the configuration changes made from the client.

What I Will Be Working On

I'll be looking for more feedback on the API Configuration PR, then working on it to get it merged before my the end of my last day of classes on Tuesday: 

https://github.com/Freeseer/freeseer/pull/632

One particular detail I need to follow up on is adjusting the above PR to take dbrenden's HTTP error changes into account, which were just merged into master. Aside from that, I'd like to write some good comments into the configuration code itself since there are a couple of outstanding issues related to the plugin framework that could be addressed by a later contributer.

Week 11

Nearing the end of term, and last week felt like the calm before a storm. A very big storm. I had two days off on monday and tuesday for the fall reading break, and used that extra time fairly effectively.

What I Worked On

I spent part of my reading week off-days looking into #654 and #658, issues related to the plugin configuration work I did earlier in the term. #654 was caused by not having a valid default value set for the USB source configuration's input property. 

My initial fix for #654 was to have the Configuration class call a method to find an appropriate default value when the Configuration instance is first created. However, this caused further issues because the method that detects compatible devices had OS-specific code in its body (see #658!). My final fix involved calling the method to detect a default input only if the plugin binary was being loaded and there wasn't already an input source selected by the user. The binary should only ever be called when the user is preparing to record and has already selected their plugins, and so no OS-incompatible plugin code should be run at that point. So far this seems to be working best.

Aside from the above issues, I also addressed some feedback for two PRs I had open at the end of last week related to both Freeseer's ProfileManager, and also to the json schemas I was adding to Freeseer's Configuration and Option classes: 

https://github.com/freeseer/freeseer/pull/643

https://github.com/Freeseer/freeseer/pull/646

I managed to get both of those merged into master, which made it possible for me to get back to working on the Configuration API endpoints. I spent a fair amount of time on the endpoints, their unit tests, and various helper methods, and have working code for most of the configuration as described in the API doc:

https://docs.google.com/document/d/1efjdlFTFlYLX0XOYs1hIjBC6rxLRXBjMjiqUdPBHqSc/

See this PR for details:

https://github.com/Freeseer/freeseer/pull/632

Issues

The main issue i have run into, which is serious enough to block progress on a couple of the Configuration endpoints, is that Freeseer's PluginManager does not track instances for plugins.

1 - It's also currently not possible to determine which particular instance of a plugin is being used by an audio or videomixer from its configuration.

2 - PluginManager doesn't keep track of how many instances have been created for some plugin.

3 - There is no way to get all of the existing instances for a plugin from PluginManager.

These points are all ultimately related to this old issue:

https://github.com/Freeseer/freeseer/issues/416

What I Will be Working On

I will mostly be working on addressing feedback for #632, and on updating and editing the API configuration docs. Aside from the two endpoints that I cannot implement without larger changes to the PluginManager, the API configuration is currently in working condition and hopefully can still be used as a starting point for any further work related to making a headless Freeseer server.

Week 10

The past week was a particularly busy one due to the convergence of various assignments and a lot of additional work grading projects for the class that I TA. I wasn't able to get nearly as much done on Freeseer as I had hoped, although it wasn't a total loss since I did add to and improve two of the PRs that I have open.

What I Worked On

This week I mainly added to and responded to feedback on two pull requests I currently have open:

Expands ProfileManager and profile unit tests:

https://github.com/freeseer/freeseer/pull/643

For this request I mostly just responded to feedback on the PR, renaming some methods, adding more unit tests for the new methods, etc.

Add schema methods to options and Config files:

https://github.com/Freeseer/freeseer/pull/646

I added code to produce 'default' properties in the Option schemas when options have their default values set. I moved the option-specific schema tests into the test classes for their individual Option classes. I created a test_float.py file to test FloatOptions, which was previously missing from the test suite. Aside from that, I mostly just adjusted code in response to feedback on the PR.

What I Will Be Working On

I was unable to get the above two PRs merged this past week, so this is my first priority for the coming week. Once both of these PRs are in, I can resume implementing the endpoints on the Configuration API here: 

https://github.com/Freeseer/freeseer/pull/632

Week 9

I could tell this week that we're getting into the late fall and nearing the end of the semester. Not from the weather, of course, since I spent all week sitting indoors at school: I could tell because my various class assignment deadlines are so unreasonably close together, and the labs are packed even on weekend nights. I always wonder why most classes seem to present about 50% of the assigned work in the last 25% of the term.

This means it's also the UCOSP home stretch! I spent this past week trying to implement features needed for the Configuration API that are missing from the Freeseer ProfileManager, as well as adding json-schemas to the Configuration and Option classes.

What I Worked On

Some of the functionality needed from Freeseer's ProfileManager for remote Configuration is missing, or just unimplemented: Listing profiles, deleting profiles, and explicit creation of Profiles. I extended the ProfileManager class to add this functionality so that it can then be used by the Configuration API. This work is here:

https://github.com/Freeseer/freeseer/pull/643

I then spent some time reading and learning about json-schema from here (http://json-schema.org/), so that I could add methods to both the Options and Config classes that returned their schemas. This functionality will be useful for the Configuration API, as it makes validation of a user's PATCH requests much simpler, and also makes it easy to tell a user what form their requests need to be made in. The work for json-schemas is here:

https://github.com/Freeseer/freeseer/pull/646

What I Will Be Working On

The first part of this week must unfortunately be a Freeseer-free time for me: I have two rather large assignments due on Monday and Wednesday, along with two smaller ones also due over the same two days (seriously, who schedules these things?!).

I plan on focusing on Freeseer starting on Thursday. Hopefully the two above pull requests can get merged by then, which means I can continue to focus on the Configuration API itself:

- Implementing all of the Profile endpoints.

- Add the json-schema validation to requests.

- Re-focus on implementing the plugin endpoints.

- Any accompanying unit tests.

The bolded item may require some further tweaking of Freeseer's Config and Option classes, as noted in my notes in the Config API spec:

https://docs.google.com/document/d/1efjdlFTFlYLX0XOYs1hIjBC6rxLRXBjMjiqUdPBHqSc/edit

Week 8

This past week felt like a breather compared to the previous, even if I did have assignments due on Monday and Wednesday. I also spent some extra time on TA duties, invigilating a term test on Monday night, then a 4 hour grading session on Thursday. Regardless, I was able to spend a fair amount of time on Freeseer over the course of the week.

What I Worked On

The first task I worked on was figuring out what code changes would be necessary to implement the profile endpoints. Freeseer's ProfileManager class is fairly simple and doesn't offer explicit methods for listing, creating, and deleting profiles.

Likewise, I looked over the endpoints specified in the Config API document and started listing any other potential code modifications required to implement them. You can see some of my annotations (although some are already resolved) on the doc:

https://docs.google.com/document/d/1efjdlFTFlYLX0XOYs1hIjBC6rxLRXBjMjiqUdPBHqSc/edit

Later in the week I started working on the implementation for the configuration controller. I focused mainly on the endpoints that don't require extra code modification, but also set up 'unimplemented' stubs for the others.

I also created a test_configuration.py file and started filling in some unit tests for each of the endpoints. Again, many of these simply test for the 'unimplemented' response for now, since the endpoints themselves are not yet coded. I had to spend a bit of reading time on practices for unit testing Flask apps, and going over the existing test_server code to figure out how to best test the configuration app.

All of the configuration work can be seen in this WIP pull request:

https://github.com/Freeseer/freeseer/pull/632

What I Will Be Working On

Over the next week I will continue to flesh out both the unit tests and the implementation code for the configuration api. 

If I have extra time, I may return to an issue I ran into while originally refactoring plugins that required ChoiceOptions, since it affects both the configuration API and possibly also the issue I opened last week:

https://github.com/Freeseer/freeseer/issues/636

I initially explained the issue with ChoiceOption plugins and unsupported devices in this doc:

https://docs.google.com/document/d/16tRySYdZIaKww8L32wWFMSMX67ifXy77VjNh3zSBWd8/edit

Week 7

This past week was the busiest school week yet. Midterms really threw a wrench in my usual plans for managing the workload. I also happen to have assignments due on the first three days of the coming week, so I have spent all of the weekend at home doing work. That said, my schedule looks like it's clearing up a little after Wednesday, so I may actually get to spend next weekend doing something other than schoolwork!

What I Worked On

Earlier in the week I met with mtomwing over IRC and got some excellent feedback on the Configuration API draft that I started writing a couple of weeks ago. I reworked most of the Configuration endpoints based on his feedback. These can be seen here:

https://docs.google.com/document/d/1efjdlFTFlYLX0XOYs1hIjBC6rxLRXBjMjiqUdPBHqSc/

Later in the week, I spent some time debugging an issue with the refactored plugins code where different instances of a plugin were being saved under the same section in the plugin.conf file. I fixed that issue, made a few other suggested changes and improvements, and the plugins refactoring PR was merged into master! 

While testing the plugins code I also discovered a quirk with the plugin settings widgets: hitting 'close' on a settings window does not save the configuration, so for some of the plugins the default settings shown in their config widgets don't match the settings actually written to file until the user actively changes them. I opened an issue with a more detailed description:

https://github.com/Freeseer/freeseer/issues/636

What I Will be Working On

This week I want to prioritize work on the Configuration API, as I think there will probably be many details to work out once I start delving into implementation.

I would also like to have another look at https://github.com/Freeseer/freeseer/issues/636 to see if it's possible to improve the plugin widgets by adding config.save() callback methods to their close buttons.

Week 6

This felt like a very short week: probably because we had our last meeting on tuesday due to Thanksgiving weekend travel plans. It also happened to be a very busy week for me in terms of assignments, so I can't say I got as much done for Freeseer as I would have liked.

What I Worked On

Plugins

I made some changes to the plugin refactoring PR after receiving some feedback:

https://github.com/Freeseer/freeseer/issues/588

Configuration API Spec

I made a few changes to several endpoints in the spec. The biggest change being that I completely separated the endpoints for viewing/setting the configuration profile from the endpoints that cover the configuration itself.

The spec draft can be viewed here:

https://docs.google.com/document/d/1efjdlFTFlYLX0XOYs1hIjBC6rxLRXBjMjiqUdPBHqSc/

Flask and Configuration

I spent some time reading about flask (http://flask.pocoo.org/), and going over the existing recording.py and server.py code. I started experimenting on the configuration controller implementation, and opened a WIP pull request to keep track of these experiments: https://github.com/Freeseer/freeseer/pull/632

Issues

I encountered a unit test failure while testing some of my plugin configuration changes. Strangely enough, it was related to the server tests using the user's real configuration dir and not at all related to the plugins. I opened an issue for it: https://github.com/Freeseer/freeseer/issues/629

What I Will Be Working On

I will mostly be working on the configuration.py controller and some of the related functionality. 

An enhancement I would like to see for the Config classes is to have a method that returns the Config's options wrapped as key-value pairs in a dictionary. ChoiceOption classes could be represented as a list of available options plus its selected one. This will make the implementation of the configuration endpoints much cleaner and straight-forward. I may tackle this over the next week, since it makes sense to have this enhancement before going too deep into implementing the configuration back end.

Next week also happens to be particularly busy again due to midterms and a nasty assignment due date, so I may not get much time to work on Freeseer until later in the week: probably friday and saturday. However, I will check for and respond to any feedback I get on the config API spec.

Week 5

The past weekend was Thanksgiving, and involved a bit of travelling and family time. Most of the work I did on Freeseer was from earlier in the week, although I managed to sneak in a bit of homework between bouts of Turkey meals.

What I Worked On

Plugins

I spent the earlier part of the week working Plugin refactoring. The first task I spent time on was writing up a brief description of the unsupported plugin problem I had found while refactoring the firewire plugin last week, which can see read all about in this document: https://docs.google.com/document/d/16tRySYdZIaKww8L32wWFMSMX67ifXy77VjNh3zSBWd8/edit

Given feedback from one of Freeseer's mentors, I re-visited all of the plugins that were potentially affected by the above issue and simplied their Config classes to use StringOptions instead of ChoiceOptions. 

I also spent some time converting the last plugins that were still using the old Plugin Manager configurations to use Config classes instead: Pip, VideoPassthrough, Audiofeedback, Ogg Icecast, Ogg output, Videopreview, RTMP Streaming.

https://github.com/Freeseer/freeseer/pull/589

Configuration API Spec

I did some review of RESTful API design and started on a draft for the Freeseer Configuration API Spec, documented here: 

https://docs.google.com/document/d/1efjdlFTFlYLX0XOYs1hIjBC6rxLRXBjMjiqUdPBHqSc/edit?usp=sharing

So far this spec includes endpoints for user profile, the general config page, the recording config page,  accessing plugin categories (audio, video, file, streaming) and specific plugins. I have not yet considered endpoints for the other two pages in the configuration tool.

Issues

I had an interesting issue with the Travis-CI unit tests earlier in the week. Basically, the multimedia unit tests were failing on Travis despite not failing when I ran them locally. To complicate matters, the failure on Travis was silent: There was no unit test output of any sort, and no messages specifying which particular test was failing. The test script just exited abruptly at the test_multimedia.py file.

The actual cause for the unit test failure was related to one of the plugins having a default value that was incompatible with the VM that Travis was running the tests on: The VideoPassthrough Plugin's default input was set to 'Desktop Source', which is unfortunately not supported on Travis. Changing this to 'Video Test Source' fixed the issue.

More importantly, we never did quite figure out why the unit tests were failing silently. If this happens to someone else in the future, one way of ensuring more output is to modify the ./run_tests script in the root folder of Freeseer by making this change as suggested by mtomwing:

-run_or_fail "src" "python setup.py test"

+run_or_fail "src" "py.test --verbose"

What I Will Be Working On

The coming week I plan on continuing work on both the plugin refactoring and the configuration API spec, and hope to get feedback on both. If the API spec looks reasonably good and I have extra time, then I will also start on writing the Configuration Controller class.

Week 4

What I Worked On

All of the work I did this week once again focused on refactoring existing plugin classes to work with the freeseer framework's Config class, and can be seen here (https://github.com/Freeseer/freeseer/pull/589). The overview of items I worked on is as follows:

• Finished with the audiomixer package by refactoring the MultiAudio plugin.
• Refactored all of the videoinput plugins: DesktopLinuxSrc, FirewireSrc, UsbSrc, and VideoTestSrc.
• Made the new ChoiceOptionFunction class a bit more robust in handling cases where the choice function returns no options.
• Spent quite a bit of time debugging an issue related to plugins not finding any compatible devices (described below) and the Config class' strong objections to such cases.

Issues 

In Freeseer's master branch, plugin configurations are persisted to file (plugin.conf) when the user makes any changes to the plugin's settings from inside the configuration windows, or when the user simply opens that plugin's configuration widget even if no changes are made. I wanted to fully duplicate this behavior in my branch with the new Config classes, but ran into an interesting issue while working on the firewire plugin. 

My laptop has no firewire, so naturally initializing the firewire plugin produces no selectable options for video. While the master branch handles this particular case by creating a default but fictional "/dev/fw1" entry to save in the plugin.conf file, the Config files I am working with in my branch are much stricter. Saving the plugin settings to file with a missing configuration option throws an OptionValueNotSetError. Saving to file with a fictional default value (like on master branch) throws an InvalidOptionValueError.

This same issue is causing some failures on the Travis CI tests, as some of the other plugins (PulseAudioSrc and UsbSrc) that are now using the Config files are also not detecting any compatible devices available on the Travis test VM. Since no compatible device is available, the Config file can't have a real value for that particular configuration option, and so throws the OptionValueNotSetError when the plugin's initialization code tries to read the device.

What I'll be Working On

I'll first revisit the issue I described above: I was considering extending the Options code to have an Options.NoneAvailable type as well as the existing Options.NotSpecified. This will let us explicitly record the fact that there are no compatible devices detected for a configuration. 

I'll need to review the plugins' init methods and make sure they can handle the cases where some needed option ends up being NoneAvailable. It's possible we should also alert the user when some chosen plugin finds no compatible devices, since the current code doesn't do that.

I still need to refactor the PIP (picture-in-picture), and the VideoPassthrough video plugins.

Finally, I need to start writing up a spec for the configuration system's REST api, although this task may get pushed back a week since I'm still dealing with the above plugin issues this week.

Week 3

Week 3 was a little short and less productive then I had hoped. After the 3 day code sprint last weekend, I had much work to catch up on for my other classes: readings, assignments, and problem sets that are somehow all due this upcoming week.

What I Worked On

I worked pretty much exclusively on the plugin system (#589 - refactor plugins).

JackAudio and PulseSrc Audio Plugins

The first task I visited this week was to finish converting the JackAudio and PulseSrc plugins to using their respective JackAudioConfig and PulseSrcConfig classes. This involved reworking the PulseSrc plugin's __get_sources() method so that it could be called by the ChoiceOption class used in the configuration.

I had to spend some time tracing a bug in the PulseSrc plugin initialization that was in the end caused by my change: I was not passing a valid and necessary default option for the plugin's 'source'. This just served as a reminder that our current unit tests are incomplete in their coverage, so some of the work i'm doing with the plugins requires manual testing.

ChoiceOptionFunction

I experimented with a ChoiceOptionFunction class to extend ChoiceOption: The purpose of this (as mtomwing commented on the above pull request) is so that the configuration files can be given a callable from which to generate available configuration choices at runtime, rather then receiving a static list of options which no longer change after the Freeseer starts. The use case would be for users who plugin some new peripherals (ie webcams, or usb microphones) while Freeseer is already running.

I'll have to do more work on this to make sure that all of the run-time methods that make use of ChoiceOptionFunction are overriden to use the callable, instead of ChoiceOption's static list.

Multiaudio Plugin

I started refactoring the multiaudio plugin to use its own Config file, but put it aside temporarily as I discovered the PulseSrc bug above. I have left that work set aside in my stash, and will continue on it this week.

Tig Stash is Awesome

I've gotten into the habit of using the tig command line tool (http://jonas.nitro.dk/tig/), but only recently had the occasion to discover tig's stash browsing feature with the 'tig stash show' command. Very handy way to find some bits of code that you put aside earlier.

What I Will Be Working On

1. Make sure that the plugins using the Config changes are still being persisted correctly to the user profile's plugin.confg. This will require a bit of additional refactoring.
2. ChoiceOptionFunction: Find all methods used by ChoiceOption plugins at runtime, and override in ChoiceOptionFunction as necessary.
3. Finish the Multiaudio plugin refactoring, then continue with remaining plugins.

Week 2

The Code Sprint

The Fall 2014 UCOSP code sprint was held this past weekend, hosted at the Mozilla offices in downtown Toronto. I attended the thursday evening social gathering as well as the three days for the actual sprint. It was an excellent chance to put faces to the IRC names of my Freeseer student team mates, as well as one of our mentors, Joseph.

What I Worked On

I spent much of the sprint reading the Freeseer codebase and drafting a proposal for the project that I plan to undertake this term. Freeseer currently has a basic HTTP API implementation that allows the user to remotely record and access recordings on a machine running Freeseer in server mode. As it stands, however, a user is unable to remotely access or modify any of Freeseer's configuration settings. My proposed project for term involves writing the REST API for this system.

The first concrete task I worked on once I had received some feedback about my project proposal was refactoring the existing plugin classes with the intent of making their configuration details easily accessible for the future remote config API. I opened a work-in-progress PR (#589) so as to get some quick feedback and to make sure I was working in the right direction.

I dealt with a few other miscellaneous issues over the weekend, including learning to properly rebase my pull request branch so that it could be merged into the upstream master. I also opened issues for a couple of Freeseer configuration problems I ran into while setting it up on my laptop:

1. #575 was an issue with the dev_requirements.txt file missing the Sphinx dependency.
2. #577 was a sound issue caused by missing the required gst plugin for Jackaudio.
3. #578 was a video recording issue that was fixed by installing ucview on my Fedora laptop.

What I Will Be Working On

Over the next couple of weeks I will be working on refactoring the existing plugins to use PluginConfig classes, as needed. Additionally, I will be reviewing RESTful API design so that I can write the spec for the remote configuration API. 

Week 1

Me, UCOSP, and Freeseer

My name is Francisco Canas. I am a 4th year undergrad student at the University of Toronto's Computer Science department. This fall, I am participating in the Undergraduate Capstone Open Source Project (http://ucosp.ca/) as part of my 4th year curriculum. I will maintain this blog on a weekly basis in order to share my overall impressions of the UCOSP project, and also as a status report for my team mates and mentors.

The UCOSP project that I am participating is Freeseer , an open-source, cross-platform video streaming and webcasting program. You can read all about Freeseer here: http://freeseer.readthedocs.org/en/latest/about/index.html

Preparation

In preparation for the first official week of working on UCOSP, I first spent some time ensuring that my dev environment (ie. my laptop) was capable of running Freeseer and set up with all of my usual dev tools. My goal was to have Freeseer working, and to be able to run, test, and debug the project from my IDE by the time the first week started.

The first challenge encountered was a failing test suite, and I was able to fix these failing tests by installing a couple of dependencies that were missing from my Fedora system: gstreamer-python, sphinx, and sphinx-python. 

Running Freeseer successfully also required a little bit of troubleshooting. Although the program started up fine, I was unable to successfully record any video or audio, and was seeing stack traces in the terminal when attempting to record. Once again, this issues were caused due to missing dependencies. I use Jackaudio on my laptop, and so had to install gstreamer's Jack plugin, which came in the form of the package gstreamer-plugins-good-extras. This fixed the audio recording issue, but my webcam only became accessible to Freeseer once I installed and configured ucview as detailed in these instructions: https://ask.fedoraproject.org/en/question/7456/my-webcam-does-not-work/

Week 1

What I Worked On

Most of the time I spent on Freeseer this week involved reading code and trying to understand the project's overall architecture. I also worked on some more immediate improvements to unit tests (see https://github.com/Freeseer/freeseer/pull/565).

What I Will be Working On

After a good discussion on the IRC channel about some potential additions to Freeseer's remote recording capabilities, I am considering working on a remote configuration API. Having such an API would allow users to remotely configure Freeseer, thereby opening the potential for using it as an entirely headless recording device. Before the configuration API can be started on, however, it may be very necessary to clean up the code for Freeseer's plugins. This is the area that i'll be focusing on over the next week (at least).