On 1/18/07, D. Hageman <[email protected]> wrote: > > I understand the purpose of libraries. My argument is that there is a > point of diminishing returns when you put *everything* into its own > library.
This isn't a discussion about whether everything should be its own library. It's whether freedesktop support is such a "core" function that it belongs in ecore. If you look at the existing modules in ecore, there is a fairly clear line about which ones are common to other libs and apps, and which are relatively unused or specialized. I would say that efreet falls into the specialized category. It's useful to more than a single application, but not useful for most. > I also argue (package managers or not) that eventually you need > to start thinking of end users experience besides of just "how pretty does > it look?" Anyone can argue that e17 et al hasn't been released yet so it > doesn't matter ... does this mean it will never, ever be released? What does another lib have to do with the "end user experience"? This has nothing to do with how pretty it looks. End user experience is about using the software, not compiling it (at least not for most users). We're not at the number of libraries that linking is overly burdensome on the user experience. If you're a programmer using the API's, it's about being able to easily understand how to use the API provided, and in that case there is little difference if its a separate lib or a module inside of another lib. In either case, the programmer needs a reference to know which lib provides the functionality required. > Anyone can argue a slipperly slope argument of what should go in and not go > into > something like ecore ... I believe you were the one that used that logical fallacy earlier in this message by stating that we're arguing to put everything in its own library (though that could fall under a couple other categories too). > but the truth is that something *similar* is > already there. It is logically to just replace it and be done with it > instead of contributing more to dependency/library bloat. It's true that there is already something similar in ecore, but does that mean it necessarily belongs there? If e17 and other users of ecore_desktop switch to efreet, they will have to change their code regardless if it's updating to the new ecore_desktop API or changing it to an exdg API. As far as dependency or bloat, the way ecore_desktop is used now is that it's built and installed as a separate lib, just the source is inside the ecore directory and its namespaced under ecore. So the only difference is directory location and how many times you may have to do ./configure && make && make install. The number of libs linked would be identical. I want to make it clear, I think it makes sense to have an ecore type library to collect common functionality into a central location, but I don't think the desktop functionality necessarily belongs there. ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
