Talk:API
From S1MP3 Wiki
Contents |
Dev files
Do we really need device files? Imo it's better to just create specific API calls for every specific file... it's not like we're working on a PC here, where there are lots of devices that are either block or char devices, most of the stuff that's available in mp3players isn't streaming based. I don't see what problem we're trying to solve by using device files. Sprite_tm 17:43, 8 May 2006 (CDT)
See open() pseudo-code. My idea was to have the kernel work on that scheme. Non-streamed devices won't be artificially streamed... --Legolas558 17:55, 8 May 2006 (CDT)
Mmm, I think it's a kludge anyway: either we implement dev-files, or we don't. Nofi, but I don't like this halfway thingy... Sprite_tm 18:13, 8 May 2006 (CDT)
The fact is, I currently have no idea of the possible bottlenecks we may bump into while developing the dev-files kernel. If we'll find dev-files useful at the application level (consider the debugging possibilities of an hardware that can "see" itself), we will implement them - even if hard - but if they will not fit conceptually, we will trash them. --Legolas558 03:02, 9 May 2006 (CDT)
Classes
Why the classes in the level 1 api? The core api will probably end up as a jump table or a RSTx with an arg in a anyway, so why not just return an error if that api call isn't implemented? It seems kinda logical to me that programmers don't need to expect that a radio API will be working on a non-radio device; if they do, they'll just get an error and their program can display an appropriate error message.
The idea was to have different compiled Swans depending on the class mixes. The .APP should read from a static variable the current device class and smartly understand how to work. If we have a RTMM, there is no problem...it will return the failure as expected. --Legolas558 17:58, 8 May 2006 (CDT)
Anyway I do agree with you, the class concept must be merged with the RTMM --Legolas558 03:04, 9 May 2006 (CDT)
Documentation
I am documenting the original SDK, should we describe a 'code commenting' convention?
Maybe state that we use doxygen (at least, that's what I am working with ATM, as Legolas proposed) so coders know about it?
I think it's important we only accept commented code, so it doesn't turn into a nightware of documentation work afterwards. --LKRaider 21:19, 8 May 2006 (CDT)
I agree with doxygen style comments. :) Anyway, we are just making trials here and the pseudocode will change frequently, so it is not worth to start documenting these unless we want to do it as an exercise --Legolas558 02:37, 9 May 2006 (CDT)
