No need for crawling the forums. If B3D is helping to support this, implement a simple REST interface PHP script for obtaining forum data without all the HTML. It would be trivial for them to take the current set of index/forum/thread php scripts, strip out all the HTML, and dump XML of just the relevant data.
My own personal opinion is to use Google's GDATA atom format for the dump (and also maybe support RSS later). Then, the 3D Forum Reader will not only work on B3D, but can be used to read Google Groups (USENET) and others.
I would also push to make it a browser plugin instead of a separate standalone application, so that it can be integrated with HTML panels. For example, Rys could stick an <OBJECT> tag in the PHP to invoke the plugin (if set in preferences) but still maintain the HTML ad banners and other site navigation.
Or, some more enterprising individual might want to *script* the 3D Forum Reader with JavaScript, mashing up Google Maps or Calendar, or some other Web2.0 site with 3D Forum.
Thus, given that I know it is not an alternative Web interface, I would say
1) write base in C + OGL. Make this base as small as possible.
2) event handling code, "logic" of the reader, for the UI, all done with Rhino JavaScript engine (used by Firefox). Widgets, core animation, rendering all in C, but UI events like clicks, form field entry, etc all handled in JavaScript callbacks.
Yes, it's tempting to write the entire thing in Mono or Java if it is standalone, but I think if it is a Forum interface, it should sit well in the browser and use JavaScript, so that people can embed it themselves and use it for applications. Mono/Java are too bulky for this approach IMHO.
If someone wants to make a Mono/Java/Ruby/whatever binding for it later, they can.
BTW, didn't Alex St John produce a ActiveX 3D component engine?
I would love it if someone enhanced Mozilla's CANVAS object to return a 3D Context so that you could 3D programming in the web browser with HTML + JavaScript. See http://developer.mozilla.org/en/docs/Drawing_Graphics_with_Canvas for example.
I just don't think the majority of the logic fo needs to be done in anything but JavaScript. What should probably be C is the UI Widgets themselves: 3D button, 3D HTML panel, 3D textfield, etc
The other advantage of a C + JavaScript implementation is that other sites, besides Beyond3D can easily customize it without needing to be 3D experts or C programmers.
My own personal opinion is to use Google's GDATA atom format for the dump (and also maybe support RSS later). Then, the 3D Forum Reader will not only work on B3D, but can be used to read Google Groups (USENET) and others.
I would also push to make it a browser plugin instead of a separate standalone application, so that it can be integrated with HTML panels. For example, Rys could stick an <OBJECT> tag in the PHP to invoke the plugin (if set in preferences) but still maintain the HTML ad banners and other site navigation.
Or, some more enterprising individual might want to *script* the 3D Forum Reader with JavaScript, mashing up Google Maps or Calendar, or some other Web2.0 site with 3D Forum.
Thus, given that I know it is not an alternative Web interface, I would say
1) write base in C + OGL. Make this base as small as possible.
2) event handling code, "logic" of the reader, for the UI, all done with Rhino JavaScript engine (used by Firefox). Widgets, core animation, rendering all in C, but UI events like clicks, form field entry, etc all handled in JavaScript callbacks.
Yes, it's tempting to write the entire thing in Mono or Java if it is standalone, but I think if it is a Forum interface, it should sit well in the browser and use JavaScript, so that people can embed it themselves and use it for applications. Mono/Java are too bulky for this approach IMHO.
If someone wants to make a Mono/Java/Ruby/whatever binding for it later, they can.
BTW, didn't Alex St John produce a ActiveX 3D component engine?
I would love it if someone enhanced Mozilla's CANVAS object to return a 3D Context so that you could 3D programming in the web browser with HTML + JavaScript. See http://developer.mozilla.org/en/docs/Drawing_Graphics_with_Canvas for example.
I just don't think the majority of the logic fo needs to be done in anything but JavaScript. What should probably be C is the UI Widgets themselves: 3D button, 3D HTML panel, 3D textfield, etc
The other advantage of a C + JavaScript implementation is that other sites, besides Beyond3D can easily customize it without needing to be 3D experts or C programmers.