|Here you see a list of things that need to be done which are not
chained to Milestone releases. Each task can be worked on seperatly. If you want to help developing
JCast-X send a notice to firstname.lastname@example.org and pick one of those:
If you look at PlaylistSourceThread and the way informations about MP3's are read through ID3 or
path related informations, you get a feeling why this needs a cleaner implementation :). Since JCast-X
should be able to work with all kinds of media-streams we need something that will work with MP3,
MPEG, OGG, ... and other formats. First ideas are to create some kind of SourceInfo Interface which
wraps common media informations like getArtist(), getAlbum(), getTitle(), getShortName(), getLongName()...
The SourceInfo should be able to create/fill itself from different Sources, maybe with factory
methods like create( ID3Tag), create( FilePath ), create( MPGProperties ), ...
A look at various "Builder Patterns" is probably worth it too.
When you connect to JCast-X you notice a latency between 0.1 and 3.5 seconds. This great gap is
partly because of the thread-schedulers way of assigning who is the active thread. But mainly
because of a non existing design for latency! Now since the core of JCast-X is stable and proven
to work as expected. Plus we have a unit-testing suite for the core. Now is the time to adjust the
code/design for latency.
The install.xml will work under Win32 with no problem, but the install.sh won't ;). The major part
here is to adjust all pathes to work with Win32 based systems. And maybe extra features that only
work on Win32.
Looking at PlaylistSourceThread again you will notice a lot of members and methods that deal with
calculating the delay for the streamed source. I believe all of these things can be hidden away into
another class which sole purpose is to deliver byte with variable speed. This is just an idea but
I image a method like:|
public byte delayRead( InputStream stream, int delay ) throws IOException;
I am not sure about the InputStream argument since you need to handle the threads delay, but
I believe you see where I am heading.
Now this is not as trivial as it sounds. Since the .net package deals with transporting bytes over
the network, the testing-suite would need to use some kind of client-server test. If you think you
know how to do this, or you simply would like to know how to do this ;). Tkae this task and take
With the next Milestone JCast-X will have a Servlet-Engine that supports JSP (Jetty). With that
we need some kind of cool-bleeding-edge web frontend. ;)
This task can always be done by anyone. Just get the source code from CSV, take a package and
read through the lines of code. When you find something/anything that you think is worth
talking about ( bugs, javadoc, design issues, wrong code, bad code ) submit your list of "issues"
to email@example.com. Be constructive and clear in your review if you do one,
and do not use inapropriate language ;).