Hi, I want to start this 2010 year thanking all the people that have contributed to make Dillo what it is. It's been 10 years and a long way lays behind. Lots of people have shared their time/work/advice/help/money/. After all, what we have now is the addition of all those efforts. Thanks to you all!!! On Mon, Jan 04, 2010 at 11:38:03PM +0000, corvid wrote:
Do we currently have anything that needs to be fixed/implemented before a release would be sensible?
Not that I remember. The only problem I recall was the error message you reported with cookies and later seemed to be working somehow. Besides, AFAIS the repo is stable enough to start rolling the release process. BTW, the cookie story is frustrating. Generally speaking: vested interests strive to kill commodity technologies to introduce their own and henceforward profit monopoly-like. This happens everywhere in the area we deal with e.g. HTTP, HTML, SGML, XML, scripting, flash, java, video streams, audio, cookies, AJAX, etc. Remember that not even the big players were able (nor willing) to implement the SPECS they co-designed. Dillo's game so far had been to support a subset with emphasis on efficiency and privacy. The game is never solved, the point is to decide well where to prune (see bottom line). Speaking of technology: Ten years ago it was images and tables, the FTP, then CGI, then cookies (the stateless HTTP, now with state), then frames (which faded 5 years later), then SGML (which was replaced by XML), then XML (which never succeeded over HTML tag soup). Then CSS (which is necessary these days. Despite IE never gave much for it). Somewhere in the middle there was java (and java beans), but it died. Then Flash, then AJAX, then silverlight, the cloud... IMHO, beyond the hyped technologies "du jour", Dillo is relevant as long as it's able to serve as an efficient information gathering tool, with emphasis on privacy. -- Cheers Jorge.-
Jorge wrote:
On Mon, Jan 04, 2010 at 11:38:03PM +0000, corvid wrote:
Do we currently have anything that needs to be fixed/implemented before a release would be sensible?
Not that I remember. The only problem I recall was the error message you reported with cookies and later seemed to be working somehow.
a_Dpi_send_blocking_cmd() gets upset when Dpi_blocking_read() doesn't get anything. So in the cookie dpi's srv_parse_tok(), after the Cookies_set(), I tried putting a a_Dpip_dsh_write_str(sh, 1, "text"), and that makes the error msgs go away for me.
I wrote:
Jorge wrote:
On Mon, Jan 04, 2010 at 11:38:03PM +0000, corvid wrote:
Do we currently have anything that needs to be fixed/implemented before a release would be sensible?
Not that I remember. The only problem I recall was the error message you reported with cookies and later seemed to be working somehow.
a_Dpi_send_blocking_cmd() gets upset when Dpi_blocking_read() doesn't get anything.
So in the cookie dpi's srv_parse_tok(), after the Cookies_set(), I tried putting a a_Dpip_dsh_write_str(sh, 1, "text"), and that makes the error msgs go away for me.
What if we do the following:
On Sun, Jan 10, 2010 at 02:00:35AM +0000, corvid wrote:
Jorge wrote:
On Mon, Jan 04, 2010 at 11:38:03PM +0000, corvid wrote:
Do we currently have anything that needs to be fixed/implemented before a release would be sensible?
Not that I remember. The only problem I recall was the error message you reported with cookies and later seemed to be working somehow.
a_Dpi_send_blocking_cmd() gets upset when Dpi_blocking_read() doesn't get anything.
So in the cookie dpi's srv_parse_tok(), after the Cookies_set(), I tried putting a a_Dpip_dsh_write_str(sh, 1, "text"), and that makes the error msgs go away for me.
Sorry for the long time to answer. Here's near 35 Celsius among other things... :-P You're right, there's one end expecting an answer that never comes. Something like the attached patch should be enough. Note that this bug may cause some networking delays depending on how the underlaying OS handles closing the socket when there's a blocking reader (it may try to delay the close). The patch avoids this. -- Cheers Jorge.-
Jorge wrote:
On Sun, Jan 10, 2010 at 02:00:35AM +0000, corvid wrote:
Jorge wrote:
On Mon, Jan 04, 2010 at 11:38:03PM +0000, corvid wrote:
Do we currently have anything that needs to be fixed/implemented before a release would be sensible?
Not that I remember. The only problem I recall was the error message you reported with cookies and later seemed to be working somehow.
a_Dpi_send_blocking_cmd() gets upset when Dpi_blocking_read() doesn't get anything.
So in the cookie dpi's srv_parse_tok(), after the Cookies_set(), I tried putting a a_Dpip_dsh_write_str(sh, 1, "text"), and that makes the error msgs go away for me.
Sorry for the long time to answer. Here's near 35 Celsius among other things... :-P
You're right, there's one end expecting an answer that never comes. Something like the attached patch should be enough.
Note that this bug may cause some networking delays depending on how the underlaying OS handles closing the socket when there's a blocking reader (it may try to delay the close).
The patch avoids this.
I'm a bit hesitant to return a msg if we don't plan to do anything with it, but then if we have to send back something, it does make sense to put some information in there...
On Sun, Jan 24, 2010 at 11:04:52AM +0000, corvid wrote:
Jorge wrote:
On Sun, Jan 10, 2010 at 02:00:35AM +0000, corvid wrote:
Jorge wrote:
On Mon, Jan 04, 2010 at 11:38:03PM +0000, corvid wrote:
Do we currently have anything that needs to be fixed/implemented before a release would be sensible?
Not that I remember. The only problem I recall was the error message you reported with cookies and later seemed to be working somehow.
a_Dpi_send_blocking_cmd() gets upset when Dpi_blocking_read() doesn't get anything.
So in the cookie dpi's srv_parse_tok(), after the Cookies_set(), I tried putting a a_Dpip_dsh_write_str(sh, 1, "text"), and that makes the error msgs go away for me.
Sorry for the long time to answer. Here's near 35 Celsius among other things... :-P
You're right, there's one end expecting an answer that never comes. Something like the attached patch should be enough.
Note that this bug may cause some networking delays depending on how the underlaying OS handles closing the socket when there's a blocking reader (it may try to delay the close).
The patch avoids this.
I'm a bit hesitant to return a msg if we don't plan to do anything with it, but then if we have to send back something, it does make sense to put some information in there...
That's the canonical way of doing it in DPIP. If the message sender is not interested in the answer, he can ignore it (as in this case). This allows for a simpler communication algorithm and a uniform way of dealing with DPIP messages. The patch sends an answer that says whether the cookie was set. It is easy to extend it to say what happened if the need arises. -- Cheers Jorge.-
Jorge wrote:
On Sun, Jan 24, 2010 at 11:04:52AM +0000, corvid wrote:
Jorge wrote:
On Sun, Jan 10, 2010 at 02:00:35AM +0000, corvid wrote:
Jorge wrote:
On Mon, Jan 04, 2010 at 11:38:03PM +0000, corvid wrote:
Do we currently have anything that needs to be fixed/implemented before a release would be sensible?
Not that I remember. The only problem I recall was the error message you reported with cookies and later seemed to be working somehow.
a_Dpi_send_blocking_cmd() gets upset when Dpi_blocking_read() doesn't get anything.
So in the cookie dpi's srv_parse_tok(), after the Cookies_set(), I tried putting a a_Dpip_dsh_write_str(sh, 1, "text"), and that makes the error msgs go away for me.
Sorry for the long time to answer. Here's near 35 Celsius among other things... :-P
You're right, there's one end expecting an answer that never comes. Something like the attached patch should be enough.
Note that this bug may cause some networking delays depending on how the underlaying OS handles closing the socket when there's a blocking reader (it may try to delay the close).
The patch avoids this.
I'm a bit hesitant to return a msg if we don't plan to do anything with it, but then if we have to send back something, it does make sense to put some information in there...
That's the canonical way of doing it in DPIP. If the message sender is not interested in the answer, he can ignore it (as in this case). This allows for a simpler communication algorithm and a uniform way of dealing with DPIP messages.
The patch sends an answer that says whether the cookie was set. It is easy to extend it to say what happened if the need arises.
Committed.
Jorge wrote:
On Mon, Jan 04, 2010 at 11:38:03PM +0000, corvid wrote:
Do we currently have anything that needs to be fixed/implemented before a release would be sensible?
Not that I remember. The only problem I recall was the error message you reported with cookies and later seemed to be working somehow.
Besides, AFAIS the repo is stable enough to start rolling the release process.
The matter of the display code prompts the question of where we want to draw a feature freeze line.
On Wed, Jan 13, 2010 at 07:54:52AM +0000, corvid wrote:
Jorge wrote:
On Mon, Jan 04, 2010 at 11:38:03PM +0000, corvid wrote:
Do we currently have anything that needs to be fixed/implemented before a release would be sensible?
Not that I remember. The only problem I recall was the error message you reported with cookies and later seemed to be working somehow.
Besides, AFAIS the repo is stable enough to start rolling the release process.
The matter of the display code prompts the question of where we want to draw a feature freeze line.
Yes, that's the question. I think the display stuff will need about three weeks until we can release it. If we want to release earlier I would leave it out. Cheers, Johannes
participants (3)
-
corvid＠lavabit.com -
jcid＠dillo.org -
Johannes.Hofmann＠gmx.de