new dev branch stuff

[David Fraser]

Brian J. Tarricone wrote:

> Benedikt Meurer wrote:
>
>> Last but not least "lightweight": This is pretty easy to explain, now 
>> that I have explained the other terms. For me, "lightweight" doesn't 
>> mean, that it consumes less memory than xx MB. Thats completely 
>> stupid! For many applications, it can be very useful and 
>> "lightweight" to consum more memory (e.g. keeping data cached to 
>> avoid disk seeks, etc.). I think of "lightweight" as: fast startup 
>> (if the use case allows it) or atleast a smooth startup (which means, 
>> the application should be usable once you see the main window), good 
>> response time (applications should respond immediatly to button 
>> clicks, etc.) and few dependencies (this sometimes conflicts with 
>> "well-designed", esp. when you start to reinvent wheels, and here one 
>> needs to find a good balance).
>
> good, i'm with you here.  i personally think that "lightweight" does 
> include the general idea of saving memory when you can, but 
> perceptible performance should always have a higher priority, and it's 
> acceptable to sacrifice RAM for speed.  dependencies i think of as 
> "not my problem".  for practical concerns, i *do* worry about them, 
> but i see that as more of a distro/packaging issue.  if the distro 
> isn't willing to package my dependencies and make it easy for the user 
> to install them, then the user isn't going to (easily) be able to run 
> my software.  i can live with that.  sometimes i like reinventing the 
> wheel for the experience ("hey, i've never coded anything like that 
> before; let's learn how to do it"), but tested, mature implementations 
> are always preferable, if available.  at the same time, i'd prefer not 
> to drag in a huge multi-function utility library just for one small 
> part of it.  i tend to prefer to just import the code in question 
> directly into my tree in that case (yes, after i drop gtk 2.2 support 
> for xfmedia [0.7.0 probably], i'll ditch libexo-lite and use the 
> shared library).

The interesting thing here is that the decision about sacrificing RAM 
for speed may depend on how much RAM is available. So if all the 
developers have lots of RAM, they may find that they can speed things up 
by using lots of it, but on an old system (like the Linux lab that I set 
up at my church) this may in fact slow things down.
An example is parsing XML files and storing caches of them. I often 
wonder whether a better design can avoid the decision altogether :-)

David