Changes

Jump to navigation Jump to search
no edit summary
Line 1: Line 1: −
Here are a few of the most obvious development issues:
+
Here are a few of the most obvious development issues/questions/comments:
 +
* Will the laptops and/or an emulator be available to developers interested in direct contibutions to OLPC?
 
* memory footprint of applications
 
* memory footprint of applications
 
* memory leaks
 
* memory leaks
 
* required flash footprint of the application; if it is big, there may not be space.  However, JFFS2 does data compression, so don't presume that the size of a file in a conventional file system corresponds to the actual amount of flash used.  As a *rule of thumb*, expect a factor of 2 compression for text and typical data, expect no compression on already compressed content, but take actual measurements to understand what your actual flash usage will be.
 
* required flash footprint of the application; if it is big, there may not be space.  However, JFFS2 does data compression, so don't presume that the size of a file in a conventional file system corresponds to the actual amount of flash used.  As a *rule of thumb*, expect a factor of 2 compression for text and typical data, expect no compression on already compressed content, but take actual measurements to understand what your actual flash usage will be.
 
* your application should be engineered and packaged to make it easy to strip unneeded functionality. For example, GAIM supports just about every IM protocol in existance, but we can only anticipate 3 being common. So the fact it uses plugins that we can choose to not package saves greatly on its footprint, whereas if everything were built in, both the memory and flash footprint would be much larger.
 
* your application should be engineered and packaged to make it easy to strip unneeded functionality. For example, GAIM supports just about every IM protocol in existance, but we can only anticipate 3 being common. So the fact it uses plugins that we can choose to not package saves greatly on its footprint, whereas if everything were built in, both the memory and flash footprint would be much larger.
* ability to operate applications when running in grayscale mode
+
* ability to operate applications when running in black/white mode
 
* the 640x480 effective resolution in color mode: some applications will find this hard, even though the frame buffer will always be in high resolution.  If your application does not honor the font resolution change-on-the-fly mechanisms, or hardwires fonts by pixel size, your application won't be able to switch modes gracefully and may require manual intervention to be usable.  Please fix.
 
* the 640x480 effective resolution in color mode: some applications will find this hard, even though the frame buffer will always be in high resolution.  If your application does not honor the font resolution change-on-the-fly mechanisms, or hardwires fonts by pixel size, your application won't be able to switch modes gracefully and may require manual intervention to be usable.  Please fix.
 
* the hardware does support alpha blending (Porter-Duff compositing), so we expect to eventually support this well
 
* the hardware does support alpha blending (Porter-Duff compositing), so we expect to eventually support this well
Line 17: Line 18:  
* looping waiting for events eats power; don't do it.  Poll and select with timeouts are your friends.  Don't gratuitously wake up at frequent intervals just to test if something has happened; design your hardware and software to be completely idle between events they have to respond to.
 
* looping waiting for events eats power; don't do it.  Poll and select with timeouts are your friends.  Don't gratuitously wake up at frequent intervals just to test if something has happened; design your hardware and software to be completely idle between events they have to respond to.
 
* presuming that you can contact a server for service will often not be possible. Design applications to be peer-to-peer, or to self elect servers in a local cloud of people working together. We can presume at least some technology like mDNS (e.g. Avahi) is available for discovery.
 
* presuming that you can contact a server for service will often not be possible. Design applications to be peer-to-peer, or to self elect servers in a local cloud of people working together. We can presume at least some technology like mDNS (e.g. Avahi) is available for discovery.
 +
* applications should be localizable. Do not embedd any user readable text in your code.
    
This page is a stub.  Please expand on it.
 
This page is a stub.  Please expand on it.
Anonymous user

Navigation menu