On Wed, 30 Nov 2011 11:19:51 +0100 [email protected] wrote: > Hello Juan,
Hi Rune, > Don't take this as an attempt to discourage you, but may be your > efforts deserve a more promising area to be applied to? > I'm grateful to receive any opinions :) > The current trend in the "web world" is to let web browsers to act as > advanced and feature-rich virtual machines for applications run on behalf > of web sites. Yes, the clock that mesures the time in computing history is a pendulum clock that alternates between running things in the server and running things in the client. It takes always a different look, but it's always the same. Web browsers started in the "run on server" side and now are everyday more in the "run on client" side (even including a lightweigh -for the moment- integrated database). > > This is hardly compatible with being lightweight :( > Let me explain later in more detail what my intention was. > There are "lightweight web browser" projects, not connected to LXDE, > but I would not expect this succeed in the long run - the applications > to be run inside the web browsers become always more demanding. Yes, they don't look too promising, but they just work in many cases. > On the other side if you manage to implement all the "crucial" features > without bloating the browser, it would be a big win - but I guess this > would need a major and sustained effort, directed at a moving target. I'm perfectly aware of the huge dimensions of a project to build a full-featured web browser from scratch, specially if the intention is to make it lightweight. I'm an old hand (hope the translation from Spanish is right) in computer engineering. Of course I didn't plan to do it alone and I also didn't expect to do it in one weekend ;) My intentions are: - Develop a native LXDE browser. This means taking the maximum profit from LXDE libraries that are loaded anyway and, hence, reduce the effective size of the application. As I'm totally new in this environment (but very excited about it) I have no idea about what are its core libraries. I also don't expect them to be veeery useful, as the environment wouldn't be lightweight if its shared libraries were too complete. - Follow the basic idea of LXDE of being lightweight. The approach to such a big project, in a way that allows the result to be lightweight (or at least with a customizable weight) was to make it completely modular, plug-in based for absolutely everything. For example (though some things make no sense nowadays, they can be ilustrative): - HTTP 1.0 module - HTTP 1.1 module, using 1.0 module. - HTTPS module (probably using openssl) - Modules for other protocols, like ftp. - HTML 4 module - XHTML 1.0 strict - XHTML 1.0 transitional (based on strict module) - Common scripting module. Based on it, - ECMAScript module - JavaScript module - Mozilla plugin compatibility layer module - Etc, etc, etc. This way maaany people in the community could contribute with small modules, lightweight each one of them, without interfering with each other, as long as there's some control about what is going on. And with many contributors, the project could hopefully be succesful. The idea is that modules could be installed or not, enabled or not and, even enabled, only loaded if really used (and even autounloaded after a timeout if not in use). To make it as lightweight as possible, but to make the huge project easier to develop/maintain, it could be written in C++ (hopefully 2011) the more ISO-compliant and portable, the better. I have experience in C++ for tiny embedded systems (concretely sensors) and results are surprisingly good, if you know what parts of C++ to use and what parts to avoid. Also, Boost libraries, mostly template-based, make a good (and almost-standard) choice to ease development without increasing weight. I even have my own implementation of C++ algorithm header file intended for memory-constrained systems, that could be handy for this project and even for others in LXDE (no miracles on this: if you choose an O(1)-space sorting algorithm, like heapsort, don't expect it to run as fast as mergesort, introsort or timsort, for example, but it can still be O(n log n) time and save a lot of memory, as sorting is used everywhere). I still have to test how gcc implementation behaves in memory-constrained systems, but OpenMP could make an extremely easy and straightforward way to implement multithreading. For XML processing, I'll try to weigth xerces-c and xalan-c. This is getting too long, sorry. The last consideration is whether to use an existing web engine, but my feeling is that they are heavy-weight, though I don't know much about them. That's it. It's very ambitious, but it can be done, if not in a hurry an if people are interested in getting involved on it. My idea is to build the basic architecture and libraries, establish coding guidelines and start developing the core modules. I'm trying to cheat a fellow who is a magician of client-side web development and could make real miracles with a rendering engine. What do you people think about this. Am I too crazy? ;) Any contribution/idea/support/warning is welcome. Cheers, Juan ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d _______________________________________________ Lxde-list mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/lxde-list
