On Sun, Nov 08, 2009 at 10:15:43AM -0300, Jorge Arellano Cid wrote:
On Sat, Nov 07, 2009 at 07:23:43PM +0100, Johannes Hofmann wrote:
On Sun, Nov 01, 2009 at 06:24:18PM -0300, Jorge Arellano Cid wrote:
Hi,
Today the big work on DPI/DPIP was committed!
The new framework and API is easier to use and more powerful. Lots of bugs and constraints were removed in the process. It was a lot of work but now is easier to fix and implement new things. After all the DPI framework was growing as new needs arose and it needed a rewrite since long ago.
There're still pending patches and docs. Details are in the Changelog and Mercurial repo (hg log -v|less).
One of them is the new select() based file dpi. It should be faster and use less resources (all happens in a single process now).
Note: currently the code uses Internet Domain sockets instead of Unix domain sockets. This was initially meant for MINIX, but in the process several bugs were fixed, the code restructured, added more error handling and improved in general. In the future we may go back to UDS, but the cleanup gains will remain.
Please test and enjoy.
For now I can just confirm that it works nice on DragonFly :-)
Excellent.
Do you think it would be a good time now, to look into the view source dpi thing again?
The buffer size constraint and atomicity transfer hope (left to the OS) were removed. DPIP implementation handles it internally now.
I was planning to work on the view source dpi a bit and at least advance it until the dpi gets the whole file so you can do the funny part. I can't but feel a bit guilty by the work you have put on it only to discover the framework was not up to the task. The DPIP framework grew by extending it to each new dpi needs, and there were constraints. This rewrite was necessary to make it more reliable in the concept, and not ad-hoc to the task.
No problem at all. I'm glad if things get simpler.
BTW, I still have to turn https into a server dpi to remove the dialog-storm bug, and to give a look into the cookies dpi to make it distinguish among different instances of dillo. View source is the first on the list, so if I were you I'd keep working on the scrolling patch and wait until Jorge commits. :) Or at your own choice let him finish the whole view source thing!
I have updated the scrolling patch, but came to the conclusion, that it is not a good idea - at least not in the way I did it originally: I have made the scrollbars part of the UI and ripped out the code that deals with scrollbar widths in layout.cc. But then I thought about frames, and there we potentially need scrollbars for every frame. So for now will leave things as they are and focus on fixing real bugs. Cheers, Johannes