zildan
22-09-10, 21:28
OSCam 1.00
am happy to announce that today trunk rev. 3144 has been baptized to OSCam 1.00 .
Source code of this release: http://streamboard.gmc.to:8001/browser/tags/1.00
Binaries can be found on the build-server:
http://www.ump2002.net/index.php?&direct...directory=OSCam , filename:
oscam-svn3144-full-Distribution.tar.gz
(high bandwidth download server seems to be out right now...)
With this step the way is open to integrated "threaded" branch into trunk. This, however, will generate bugs and instability, therefore please use OScam1.00 in your production environments.
Making OSCam threaded will have large impact on OSCam, lots of code will change, but it will bring us a lot of advantages:
1) removal of boundaries on max. nr of readers and max. nr of users is possible; if implementation is complete, only the memory/cpu boundaries of your hardware will determine the number of parallel readers, proxies and users.
2) dynamic interaction possible between readers and main program. Stuff like automatic, dynamic configuring a reader instead of static configuration through oscam.serve will become possible
3) lower usage of memory
4) easier debugging possibilities for developers
5) simpler code with less chance on bugs...
Only disadvantage is that we have to change a lot of code, but hey, that's why we are here for ...
am happy to announce that today trunk rev. 3144 has been baptized to OSCam 1.00 .
Source code of this release: http://streamboard.gmc.to:8001/browser/tags/1.00
Binaries can be found on the build-server:
http://www.ump2002.net/index.php?&direct...directory=OSCam , filename:
oscam-svn3144-full-Distribution.tar.gz
(high bandwidth download server seems to be out right now...)
With this step the way is open to integrated "threaded" branch into trunk. This, however, will generate bugs and instability, therefore please use OScam1.00 in your production environments.
Making OSCam threaded will have large impact on OSCam, lots of code will change, but it will bring us a lot of advantages:
1) removal of boundaries on max. nr of readers and max. nr of users is possible; if implementation is complete, only the memory/cpu boundaries of your hardware will determine the number of parallel readers, proxies and users.
2) dynamic interaction possible between readers and main program. Stuff like automatic, dynamic configuring a reader instead of static configuration through oscam.serve will become possible
3) lower usage of memory
4) easier debugging possibilities for developers
5) simpler code with less chance on bugs...
Only disadvantage is that we have to change a lot of code, but hey, that's why we are here for ...