Proposed Changes Options

[Guest_dns_*]

Below are some changes that i would like to have implemented eventually.

1) do some refactoring of the source code, currently all source files are not in a pakcage, At minimum all the serverlet pices should be put in thair own package and have the package sealed to stop any potential security problems. Though I have not found a way to exploit this it is somthing that can easily take advantage of some of the built in jar security features.

2) would it be possible to bundle the source code with web sheduler? or put it on the same download page?

3) Do you have any future plans for the code? any features you want implemented?

4) I would like to work on modifying the epg matching code to allow for future expansion such as Epg Match For Extra Fields and Once A Week it should also be flexable enough to add things we have not thaught up yet (ie write an api for expansions).

5) Move towards useing a database for storeing the epg data, this should be done in a way that allows the user to select what database they want and still allow for useing the data files as we are currently useing. One option is to use the Apache Derby database, it is a small database that can be embeded within a jar file. This is probly something long term that i would like to do, if i try and do it things should still work with the old behavior.

6) Change the data source fetching to allow for more than one data source to be used and the imported data to merge together, it would be easyer to use a database but it still could be done to output an xml document.

[null_pointer]

1) do some refactoring of the source code, currently all source files are not in a pakcage, At minimum all the serverlet pices should be put in thair own package and have the package sealed to stop any potential security problems. Though I have not found a way to exploit this it is somthing that can easily take advantage of some of the built in jar security features.

cool but not really needed, if someone has access to your machine to replace or edit local files your machine is toast and there is not much that can be done about it.

2) would it be possible to bundle the source code with web sheduler? or put it on the same download page?

at the moment I am only supplying source on request via email.

3) Do you have any future plans for the code? any features you want implemented?

no, stick a fork in it, it is done.

4) I would like to work on modifying the epg matching code to allow for future expansion such as Epg Match For Extra Fields and Once A Week it should also be flexable enough to add things we have not thaught up yet (ie write an api for expansions).

have fun with the API :-) I tried to write WS as open and easy to follow as possible, adding an API layer will only restrict future growth and make it very hard to maintain, well that is my opionion anyway.

5) Move towards useing a database for storeing the epg data, this should be done in a way that allows the user to select what database they want and still allow for useing the data files as we are currently useing. One option is to use the Apache Derby database, it is a small database that can be embeded within a jar file. This is probly something long term that i would like to do, if i try and do it things should still work with the old behavior.

why, the EPG data gets loaded at start time into memory and that is it, it is not that much data and WS reloads it as needed or prompted. I think a tool to consolidate EPG data is a good idea but it does not belong in WS, by the time WS gets the EPG data it should be clean and complete.

6) Change the data source fetching to allow for more than one data source to be used and the imported data to merge together, it would be easyer to use a database but it still could be done to output an xml document.

again a tool to do this for you is the place to put this functionlity, adding ectra conplexity to WS just to get the data is a mistake, it give you more places WS can fail. A tool set to manage EPG data is a much better option and can be used for any app that needs a clean EPG data source. Adding a lot of logic to a TV app to work out how to get the EPG data is the wrong approach.

All of the above are just my thoughs, I could be wrong and any of them.

[kuni]

Below are some changes that i would like to have implemented eventually.

1) do some refactoring of the source code, currently all source files are not in a pakcage, At minimum all the serverlet pices should be put in thair own package and have the package sealed to stop any potential security problems. Though I have not found a way to exploit this it is somthing that can easily take advantage of some of the built in jar security features.

2) would it be possible to bundle the source code with web sheduler? or put it on the same download page?

3) Do you have any future plans for the code? any features you want implemented?

4) I would like to work on modifying the epg matching code to allow for future expansion such as Epg Match For Extra Fields and Once A Week it should also be flexable enough to add things we have not thaught up yet (ie write an api for expansions).

5) Move towards useing a database for storeing the epg data, this should be done in a way that allows the user to select what database they want and still allow for useing the data files as we are currently useing. One option is to use the Apache Derby database, it is a small database that can be embeded within a jar file. This is probly something long term that i would like to do, if i try and do it things should still work with the old behavior.

6) Change the data source fetching to allow for more than one data source to be used and the imported data to merge together, it would be easyer to use a database but it still could be done to output an xml document.

7. Spell check your posts, before making them ;-)