Menu
▾
▴
express-devel
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
(27) |
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|---|
|
From: Brian St . P. <bst...@me...> - 2000-04-07 05:45:08
|
The commit from tonight enables express to load pages that are sent with a Transfer-Encoding of "chunked". I also put in a little (very little) better checking so that we can pick from one of a few different ways of reading content from the server, according to the http headers. There are still some crashes. The biggest one is from an assertion when we try to load an image that doesn't have an absolute URL. I will try to fix this soon, but if anyone else wants it: the fix neds to go into browser.c, in browser_load_image(). slashdot loads better, but you won't get past the front page (see bug above) yahoo loads pretty good sourceforge is unloadable (see bug above) express.sourceforge.net works ok, screenshots won't show up (see bug above) Obviously, fixing the image-loading bug will be my next priority... -Brian |
|
From: Brian St . P. <bst...@me...> - 2000-04-01 17:00:12
|
On Fri, Mar 31, 2000 at 09:06:01PM +0200, Uwe Hermann wrote: > On Fri, Mar 31, 2000 at 02:08:19PM -0500, Brian St . Pierre wrote: > > When you update to cvs, you will be happy to see that we are now > > retrieving images. >=20 > Great. The basic functionality is there. It still has some problems, but > I think they come from the URL-code. Try to display slashdot for an examp= le. > I'll have a look at the code soon, I often get segfaults together with > g_assert()s that failed... Hmmm. I just looked at slashdot. The apache server they have running is broken (?). The way I read the rfc (and I may be wrong) is that line-endings are supposed to be CRLF pairs. slashdot is putting out LF only. The code I have right now says "corrupted header, aborting". I'll correct this soon, which will make us friendlier to non-compliant servers... -Brian |
|
From: Brian St.P. <bst...@me...> - 2000-03-31 18:43:34
|
> On Fri, Mar 31, 2000 at 02:08:19PM -0500, Brian St . Pierre wrote: > > When you update to cvs, you will be happy to see that we are now > > retrieving images. > > Great. The basic functionality is there. It still has some problems, but > I think they come from the URL-code. Try to display slashdot for > an example. > I'll have a look at the code soon, I often get segfaults together with > g_assert()s that failed... I'll take a look at that. It is probably either in http_stream_get_response or open_url. > > Today, I hacked together a small tgz with a GUI for Express. It's > written with glade, which generates all the necessary stuff for you, > e.g. autoconf-stuff, gettext-stuff, gnome-macros, -includes etc. > > It took me 10 minutes to make the small demo-distribution at > http://express.sourceforge.net/express-0.1.tar.gz > > > I really think glade is the way to go. We can rewrite the whole GUI very > fast with it, and then just cut'n'paste the 'meat' of Express into the > new framework. Then we have all the advantages of GNOME, plus > additional gettext support can be added quite easily in the future... Sounds good. I'm content to work on "meat" for the time being anyway. You can change the front end to whatever suits you... -Brian |
|
From: Uwe H. <uh...@bi...> - 2000-03-31 18:15:37
|
On Fri, Mar 31, 2000 at 02:08:19PM -0500, Brian St . Pierre wrote: > When you update to cvs, you will be happy to see that we are now > retrieving images. Great. The basic functionality is there. It still has some problems, but I think they come from the URL-code. Try to display slashdot for an example. I'll have a look at the code soon, I often get segfaults together with g_assert()s that failed... Today, I hacked together a small tgz with a GUI for Express. It's written with glade, which generates all the necessary stuff for you, e.g. autoconf-stuff, gettext-stuff, gnome-macros, -includes etc. It took me 10 minutes to make the small demo-distribution at http://express.sourceforge.net/express-0.1.tar.gz I really think glade is the way to go. We can rewrite the whole GUI very fast with it, and then just cut'n'paste the 'meat' of Express into the new framework. Then we have all the advantages of GNOME, plus additional gettext support can be added quite easily in the future... Uwe. -- Uwe Hermann <uh...@bi...> http://www.bingo-ev.de/~uh1763/index.html ----------------------------------------- :wq |
|
From: Brian St . P. <bst...@me...> - 2000-03-31 06:12:58
|
When you update to cvs, you will be happy to see that we are now retrieving images. I'm still missing quite a bit of HTTP, but I got 302 "found" redirection working. It seems almost functional now. The display is still somewhat cluttered sometimes. The "cache" for images is just numbered .gif files in the /tmp directory. It was really quite a quick hack. I should have more to commit this weekend or early next week. Please let me know if you see any major problems (it is late and I'm wondering if I might have screwed something up :). -Brian |
|
From: Brian St.P. <bst...@me...> - 2000-03-28 19:18:09
|
I asked about gtk-xmhtml on the gnome-devel list and got the following response. We might want to think about switching to gtkhtml eventually (post release 1). For now, I'm putting in image support using gtk-xmhtml. -----Original Message----- From: mi...@he... [mailto:mi...@he...] Sent: Tuesday, March 28, 2000 8:22 AM To: Brian St . Pierre Cc: gno...@gn... Subject: Re: gtkhtml ? Importance: Low > I was about to ask about gtk-xmhtml when I saw the messages about > gtkhtml. Does this mean that gtk-xmhtml is now unsupported? If so, > how stable is gtkhtml (or how quickly is it going to be stable :) We are dropping support for GtkXmHTML in the next release of GNOME, and there are few bug fixes that are being added to GtkXmHTML now anyways. At this point, I am inclined to think that GtkHTML is a much more robust platform to develop for. Miguel. |
|
From: Uwe H. <uh...@bi...> - 2000-03-28 00:19:45
|
On Sun, Mar 26, 2000 at 12:29:09PM -0500, Brian St . Pierre wrote: > Do you know where I can find documentation on the gtk-xmhtml library? > I can't seem to find any good documentation (other than the header > files)... Well... there's the documentation of the original XmHTML at http://www.xs4all.nl/~ripley/XmHTML/ I don't know any gtk-xmhtml specific documentation, yet. But I can imagine that there's some stuff in the GNOME mailing-list archives. > > What do you think - should we first make a release with the stuff we > > already have, or try to 'gnomify' Express before a release? > > That depends on a few things: > - When do you want to release? Quite soon. You know, release early, release often.. > - What functionality do you want in the first release? The current + image-loading and the main points we discussed in a previous mail. > - How "gnomish" would you want to be before a release? This is of lower importance. [Todo:] > - implement more of HTTP > - fetch remote images and display them > - fix the problems with the back and forward buttons (the back button works > some of the time, but there are still bugs) > - make it more stable, there are still some very easy ways to crash it ACK. Uwe. -- Uwe Hermann <uh...@bi...> http://www.bingo-ev.de/~uh1763/index.html ----------------------------------------- :wq |
|
From: Brian St . P. <bst...@me...> - 2000-03-26 17:31:12
|
Do you know where I can find documentation on the gtk-xmhtml library? I can't seem to find any good documentation (other than the header files)... > I just played around with some GNOME-stuff. I'd like to convert Express > to a completely GNOME-based app. This would involve several changes, > e.g. we can use GNOME for the About-box, Menu-bar, Status-bar, icons etc. > I already hacked together a version of Express with all the > GNOME-libraries etc. correctly checked in configure.in / > src/Makefile.am, though it still had some problems with a segfault... The great thing about switching to being fully "gnome compliant" is that we can do it gradually. I.e. First switch the main window, then the menus, the dialogs, etc. > What do you think - should we first make a release with the stuff we > already have, or try to 'gnomify' Express before a release? That depends on a few things: - When do you want to release? - What functionality do you want in the first release? - How "gnomish" would you want to be before a release? - How stable do you want to be? I would say that if you want to release without adding any more functionality, several things have to get cleaned up: - implement more of HTTP - fetch remote images and display them - fix the problems with the back and forward buttons (the back button works some of the time, but there are still bugs) - make it more stable, there are still some very easy ways to crash it Let me know what you want and I'll try to work toward the goals. A "roadmap" might be nice. But it is a beautiful sunny day here, so I am going outside. Maybe I'll even wash my car... maybe not... -Brian |
|
From: Uwe H. <uh...@bi...> - 2000-03-26 13:47:26
|
On Sat, Mar 25, 2000 at 10:32:59PM -0500, Brian St . Pierre wrote: > On Fri, Mar 24, 2000 at 11:36:49PM +0100, Uwe Hermann wrote: > > On Thu, Mar 23, 2000 at 05:22:27PM -0500, Brian St.Pierre wrote: > > > > Stuff that, IMHO, needs to be fixed before a release: > > > > * HTTP 1.1 and 1.0 should work > > Just checked in the http module to cvs. Great stuff. Works really flawlessly. And fast (the problem with several seconds delay is gone). I just played around with some GNOME-stuff. I'd like to convert Express to a completely GNOME-based app. This would involve several changes, e.g. we can use GNOME for the About-box, Menu-bar, Status-bar, icons etc. I already hacked together a version of Express with all the GNOME-libraries etc. correctly checked in configure.in / src/Makefile.am, though it still had some problems with a segfault... What do you think - should we first make a release with the stuff we already have, or try to 'gnomify' Express before a release? Uwe. -- Uwe Hermann <uh...@bi...> http://www.bingo-ev.de/~uh1763/index.html ----------------------------------------- :wq |
|
From: Brian St . P. <bst...@me...> - 2000-03-26 03:33:48
|
On Fri, Mar 24, 2000 at 11:36:49PM +0100, Uwe Hermann wrote: > On Thu, Mar 23, 2000 at 05:22:27PM -0500, Brian St.Pierre wrote: > > > Stuff that, IMHO, needs to be fixed before a release: > > > * HTTP 1.1 and 1.0 should work Just checked in the http module to cvs. Works wonderfully -- I was able to visit several different sites without any crashes. HTTP needs to be implemented a little bit better -- it still isn't handling much of the protocol except for the initial fetches. > > > Another thing is that GNOME already has a help-browser that comes close > > > to what Express is/does. Some parts are also more sophisticated than the > > > respective functionality in Express currently is. I just tried out the gnome-help-browser (v1.0.4). It seems pretty nice, but (at least the version that I have) doesn't seem to do network fetches. So, for now at least, I'll continue working on express. I will probably look at some of their newer releases, and the code base that they have -- just to see what would be required to convert it into a general-purpose browser. The next piece that I write will perform the fetches of the remote image files contained in the current page. -Brian |
|
From: Uwe H. <uh...@bi...> - 2000-03-24 21:43:09
|
On Thu, Mar 23, 2000 at 05:22:27PM -0500, Brian St.Pierre wrote: > bounced??? hmmm.... Maybe it's a problem of my ISP or my local exim... I'll try to find out. > > Stuff that, IMHO, needs to be fixed before a release: > > * HTTP 1.1 and 1.0 should work > > Funny you mention this. I'm working on http.c, a module that will represent > a layer between tcp.c and open_url.c. In this code I'll implement the guts > of HTTP. Just a few hours of coding last night and Tuesday have resulted in > wonderful gains. Great. > > * segfaults should be reduced to a minimum > > should == MUST! If the initial release is too bad, nobody will come back > for subsequent releases... Agreed. > I would go with GNOME. From my experience on a couple of other projects, it > makes the front-end coding very easy. Most of the details for common things > are taken care of for you. OK. > > Another thing is that GNOME already has a help-browser that comes close > > to what Express is/does. Some parts are also more sophisticated than the > > respective functionality in Express currently is. > > Hmm. I haven't looked at this yet. Will do that soon; maybe I'll decide > that my efforts are misplaced... I'll let you know. > > > We have several posibilities: > > * rip code from gnome-help-browser (GPLed too, so no problem) > > * merge Express into gnome-help > > * drop Express and help developing gnome-help browser > > I would do this before either of the first two. <AOL>me too</AOL>. It's probably the best solution. We could take the code/functionality that's in Express but not in gnome-help-browser, and put it in gnome-help-browser... It's no use keeping two projects so similar to each other. > > * keep on having two different project, maybe with Express filling > > some special niche > > There may be some features/functionality that the help browser doesn't have > that we want to put into express (ftp support? other stuff like this?) I'll try to gather some more ideas for any niche that Express could fill, and that no other (or at least not many) other browsers do. If I find something, I'll probably continue development of Express... Uwe. -- Uwe Hermann <uh...@bi...> http://www.bingo-ev.de/~uh1763/index.html ----------------------------------------- :wq |
|
From: Brian St.P. <bst...@me...> - 2000-03-23 22:28:24
|
bounced??? hmmm.... > > I had some time tonight, so I've put some more fixes together. > Is anyone attached to the FORK_DOWNLOAD code in open_url.c? > > Nope. It's as good as gone, then. > IMHO, we should try to fix the most annoying stuff, so we can make a > first release (announce on freshmeat etc.). Maybe then more developers > get interested, and help developing Express. > > Stuff that, IMHO, needs to be fixed before a release: > * HTTP 1.1 and 1.0 should work Funny you mention this. I'm working on http.c, a module that will represent a layer between tcp.c and open_url.c. In this code I'll implement the guts of HTTP. Just a few hours of coding last night and Tuesday have resulted in wonderful gains. > * segfaults should be reduced to a minimum should == MUST! If the initial release is too bad, nobody will come back for subsequent releases... > * Remote images should be displayed Again "MUST"! The work that I did with url.c and the http layer that I'm creating will allow images to be fetched as a side effect. > * the URL-entry field should work correctly > * menu-icons must be there I'd prefer to stick to mostly back-end stuff (at least for now), but I agree with these too. > We should also decide whether we want Express to be dependant on GNOME > or not, and to which degree. > Currently it depends on gtk-xmhtml, which is in gnome-libs. We might use > the stock GNOME icons for the menubar, as they're in gome-libs, too. > > But any futher gnome-specific code(gnome-about-box or gnome-menu etc.) > would require gnome-core to be installed, I think. > > Do we want this? Does it matter? What do you think? > > If we make Express a real GNOME-app we should then also adapt the > GNOME-coding-style etc., of course... I would go with GNOME. From my experience on a couple of other projects, it makes the front-end coding very easy. Most of the details for common things are taken care of for you. > Another thing is that GNOME already has a help-browser that comes close > to what Express is/does. Some parts are also more sophisticated than the > respective functionality in Express currently is. Hmm. I haven't looked at this yet. Will do that soon; maybe I'll decide that my efforts are misplaced... I'll let you know. > We have several posibilities: > * rip code from gnome-help-browser (GPLed too, so no problem) > * merge Express into gnome-help > * drop Express and help developing gnome-help browser I would do this before either of the first two. > * keep on having two different project, maybe with Express filling > some special niche There may be some features/functionality that the help browser doesn't have that we want to put into express (ftp support? other stuff like this?) -Brian |
|
From: Uwe H. <uh...@bi...> - 2000-03-23 22:16:21
|
Hi Brian, I forwarded this to the list, as the mail to bst...@me... bounced... ----- Forwarded message from Uwe Hermann <uh...@bi...> ----- Date: Wed, 22 Mar 2000 16:30:23 +0100 From: Uwe Hermann <uh...@bi...> To: "Brian St . Pierre" <bst...@me...> Subject: Re: more fixes Message-ID: <200...@bi...> X-Mailer: Mutt 1.0i On Tue, Mar 21, 2000 at 09:45:39PM -0500, Brian St . Pierre wrote: > Uwe - Hi Brian. > I had some time tonight, so I've put some more fixes together. Is anyone attached to the FORK_DOWNLOAD code in open_url.c? Nope. > It doesn't look like it would even come close to compiling or working at all. Yes, I guess so too. I didn't try it, though... > I'd like to get rid of it to make the rest of the code easier to read. > > Please let me know how you feel about this -- if you want it to stay, I certainly won't touch it. Yep. Wipe it for now. If we want to implement something alike later on, we can always grab the relevant code from CVS. I didn't have much time for Express the last few days, I hope I can devote more time to it in future. IMHO, we should try to fix the most annoying stuff, so we can make a first release (announce on freshmeat etc.). Maybe then more developers get interested, and help developing Express. Stuff that, IMHO, needs to be fixed before a release: * HTTP 1.1 and 1.0 should work * segfaults should be reduced to a minimum * Remote images should be displayed * the URL-entry field should work correctly * menu-icons must be there We should also decide whether we want Express to be dependant on GNOME or not, and to which degree. Currently it depends on gtk-xmhtml, which is in gnome-libs. We might use the stock GNOME icons for the menubar, as they're in gome-libs, too. But any futher gnome-specific code(gnome-about-box or gnome-menu etc.) would require gnome-core to be installed, I think. Do we want this? Does it matter? What do you think? If we make Express a real GNOME-app we should then also adapt the GNOME-coding-style etc., of course... Another thing is that GNOME already has a help-browser that comes close to what Express is/does. Some parts are also more sophisticated than the respective functionality in Express currently is. We have several posibilities: * rip code from gnome-help-browser (GPLed too, so no problem) * merge Express into gnome-help * drop Express and help developing gnome-help browser * keep on having two different project, maybe with Express filling some special niche * ... any other ideas? Uwe. -- Uwe Hermann <uh...@bi...> http://www.bingo-ev.de/~uh1763/index.html ----------------------------------------- :wq ----- End forwarded message ----- -- Uwe Hermann <uh...@bi...> http://www.bingo-ev.de/~uh1763/index.html ----------------------------------------- :wq |
|
From: Brian St . P. <bst...@me...> - 2000-03-06 12:40:21
|
I just checked in some changes: more warnings cleanup, and improvements to the URL type. It looks like the permissions change worked -- my checkin automatically went out to the cvs list. With this checkin, you'll want to take a look at url.h. Direct accesses to URL structures are somewhat discouraged. There are operations (which may be done by macros later) on the URL type to get host, path, and protocol/port. I need to go through the code and figure out where these need to get released, because I think we're leaking the way it is written right now. I may not be able to commit any more code for a week or so, but my next mission will be to fix-up the HTTP GET code so that it operates at peak speed as we discussed before the weekend. -Brian |
|
From: Uwe H. <uh...@bi...> - 2000-03-04 21:59:48
|
On Fri, Mar 03, 2000 at 11:23:54PM -0500, Jim Garrison wrote: > Hello > > Just wondering if anybody found my message I left in the Sourceforge > forum - "open discussion." Here is the link in case you haven't: > > http://sourceforge.net/forum/thread.php?thread_id=10602 I looked through it. Please keep development-discussions on this list, as people (or at least me) don't check the forums as often as new mails, so it might take a while until your post is noticed... > I would like to see a GTK "browser" widget that combines the html > widget,networking protocols, and the buttons needed to navigate. > Then, other applications could embed the browser widget and display > web pages as well. The idea sounds great. AFAIK the gtk-xmhtml team intends to do the same with gtk-xmhtml(make a HTML-widget that can be used by lots of programs). I've never written a Gtk+ widget, neither am I a Gtk+ Guru or something, but I had a short look at the "Writing Your Own Widgets" chapter of the Gtk+ tutorial, and the code there seemed quite familiar to me. If I am not mistaken Express already has a widget for 'browser', 'bwindow' and 'alert'... I wrote a 'developers wanted'-type of news-article on Sourceforge yesterday, maybe some good Gtk+ programmer is interested in developing express and helping out in this area. Or if anyone on the list has a deeper knowledge of Gtk+, I'd be pleased to get some enlightenment :-) Uwe. -- Uwe Hermann <uh...@bi...> http://www.bingo-ev.de/~uh1763/index.html ----------------------------------------- :wq |
|
From: Uwe H. <uh...@bi...> - 2000-03-04 13:06:52
|
On Fri, Mar 03, 2000 at 09:25:17AM -0500, Brian St. Pierre wrote: > > > > > > > > I get several seconds delay between the "Request sent."-message and > > > > > > I noticed this as well, but on a (sometimes) slow connection, I just > thought > > > the network was a bit sluggish. > > > > Nope. I also get it when connecting to my local apache. And the page I > > point it to, is just 2K big, so it can't be the size of the page either. > > Ok, I figured out the problem, haven't coded a solution yet. With HTTP/1.0, > a connection is created for every request. So when we do a GET with 1.0, > the server sends us the response and then closes the connection. Our socket > sees the EOF and the call to fread() completes. > > With HTTP/1.1, a single connection may be used for multiple requests. So > when we do the GET this time, the socket remains open for 17 seconds (I > timed the call to fread()). This is how long it takes to time out and be > closed by the server. > > There are a couple of different ways to solve this, some better than others. > The best is probably to implement more of the protocol; it provides a means > of knowing how long the "content" portion of the response will be and it > also provides a way for the client to tell the server that it wishes to > close the connection after the first GET. The last one sounds like the easiest one to implement, as the code of Express (at the moment) relies on the connection being closed. Later on we can start implementing HTTP/1.1 to a greater degree... I'll have a look at the respective RFC(s), soon... Uwe. -- Uwe Hermann <uh...@bi...> http://www.bingo-ev.de/~uh1763/index.html ----------------------------------------- :wq |
|
From: Jim G. <gar...@us...> - 2000-03-04 04:27:31
|
Hello Just wondering if anybody found my message I left in the Sourceforge forum - "open discussion." Here is the link in case you haven't: http://sourceforge.net/forum/thread.php?thread_id=10602 - Jim |
|
From: Uwe H. <uh...@bi...> - 2000-03-03 00:22:56
|
Hi everyone. I *think* the automatic mails to express-cvs should work now. Please report if this isn't the case. Uwe. -- Uwe Hermann <uh...@bi...> http://www.bingo-ev.de/~uh1763/index.html ----------------------------------------- :wq |
|
From: Uwe H. <uh...@bi...> - 2000-03-03 00:06:45
|
On Thu, Mar 02, 2000 at 01:38:08PM -0500, Brian St. Pierre wrote: > > On Wed, Mar 01, 2000 at 03:54:28PM -0500, Brian St . Pierre wrote: > > > 2) We now do HTTP/1.1 GET's. This lets the > > > http://express.sourceforge.net/ URL work. > > > > I get several seconds delay between the "Request sent."-message and > > I noticed this as well, but on a (sometimes) slow connection, I just thought > the network was a bit sluggish. Nope. I also get it when connecting to my local apache. And the page I point it to, is just 2K big, so it can't be the size of the page either. > > Using a request of 'sprintf(buf, "GET %s HTTP/1.0\n\n", u->path);' works > > quite nice though. > > Some servers don't support HTTP/1.0 anymore. You'll get an error message > from http://express.sourceforge.net/, for example. True. Maybe we should have a look at the telnet-souce or the sources of other GPLed browsers to get an idea of how they handle this... Uwe. -- Uwe Hermann <uh...@bi...> http://www.bingo-ev.de/~uh1763/index.html ----------------------------------------- :wq |
|
From: Uwe H. <uh...@bi...> - 2000-03-03 00:06:39
|
On Thu, Mar 02, 2000 at 10:42:09AM -0500, Brian St. Pierre wrote: > Uwe - > > What do you think of using glib's GStrings instead of c-strings in the URL > structure? This would allow us to have dynamically sized strings for the > url and buffer instead of arbitrarily sized buffers that are given hard > limits at compile time. > > Let me know -- if you think this is a good idea, I'll work on changing it > tonight or this weekend. I like the idea. Go ahead. > If you don't like this, what would you think of > changing the URL structure to use dynamically-sized buffers for the url and > the buffer? You mean using malloc/realloc? I guess GStrings are easier to handle... Uwe. -- Uwe Hermann <uh...@bi...> http://www.bingo-ev.de/~uh1763/index.html ----------------------------------------- :wq |
|
From: Uwe H. <uh...@bi...> - 2000-03-03 00:06:37
|
Hi everyone. I'd like to wipe the following files from CVS, as proposed by Jim Garrison: Makefile.in, aclocal.m4, config.h.in, configure, install-sh, missing, mkinstalldirs, stamp-h.in, data/Makefile.in, src/Makefile.in After that, you would have to run aclocal && autoconf && autoheader && automake -a to generate some files. If you have any objections why this shouldn't be done, please say so. If there aren't any I'll delete the files soon. Uwe. -- Uwe Hermann <uh...@bi...> http://www.bingo-ev.de/~uh1763/index.html ----------------------------------------- :wq |
|
From: Uwe H. <uh...@bi...> - 2000-03-03 00:06:35
|
On Thu, Mar 02, 2000 at 01:38:08PM -0500, Brian St. Pierre wrote: > I tried both of these as well. The code seems to mimic telnet. It is > likely that using stdio streams (i.e. FILE*) is trying to buffer the input > in such a way that kills performance. I can take a look at using setvbuf to > turn buffering off. Or we could decide to use non-ANSI-C output (i.e. > system-specific open/close/read/write); but I'd rather remain higher level > and closer to standards. Ooops. I forgot this in my last mail. Conrad Parker(the original author of Express) told me that we might use libgnet for the networking code, which "implements an abstraction layer to use callbacks, and is based on glib." Let's first have a look at this one, maybe it offers an elegant solution for the problem. http://www.eecs.umich.edu/~dhelder/misc/gnet/ Uwe. -- Uwe Hermann <uh...@bi...> http://www.bingo-ev.de/~uh1763/index.html ----------------------------------------- :wq |
|
From: Brian S. P. <bst...@me...> - 2000-03-02 18:42:28
|
> On Wed, Mar 01, 2000 at 03:54:28PM -0500, Brian St . Pierre wrote: > > 2) We now do HTTP/1.1 GET's. This lets the > > http://express.sourceforge.net/ URL work. > > I get several seconds delay between the "Request sent."-message and I noticed this as well, but on a (sometimes) slow connection, I just thought the network was a bit sluggish. > Using a request of 'sprintf(buf, "GET %s HTTP/1.0\n\n", u->path);' works > quite nice though. Some servers don't support HTTP/1.0 anymore. You'll get an error message from http://express.sourceforge.net/, for example. > I telnetted to my apache directly and entered > > GET / HTTP/1.1\n > Host: localhost\n\n I did the same thing at sourceforge and yahoo. I thought telnet sent CR/LF pairs instead of just LF (see below)? > (the \n representing Enter, of course), which worked fine too, and AFAIK > your code does exactly the same thing, so I don't really know why this > happens... > > I tried to use '\r\n' and also '\r' instead of '\n', but that doesn't > work correctly either. I tried both of these as well. The code seems to mimic telnet. It is likely that using stdio streams (i.e. FILE*) is trying to buffer the input in such a way that kills performance. I can take a look at using setvbuf to turn buffering off. Or we could decide to use non-ANSI-C output (i.e. system-specific open/close/read/write); but I'd rather remain higher level and closer to standards. -Brian |
|
From: Uwe H. <uh...@bi...> - 2000-03-02 18:25:40
|
On Wed, Mar 01, 2000 at 03:54:28PM -0500, Brian St . Pierre wrote: > I just checked in a batch of changes that: > > 2) We now do HTTP/1.1 GET's. This lets the > http://express.sourceforge.net/ URL work. I get several seconds delay between the "Request sent."-message and the display of the HTML-page. I ran Express in gdb, the fread() in line 213 in open_url() seems to block... nread = fread(u->buf, 1, len, s); Using a request of 'sprintf(buf, "GET %s HTTP/1.0\n\n", u->path);' works quite nice though. I telnetted to my apache directly and entered GET / HTTP/1.1\n Host: localhost\n\n (the \n representing Enter, of course), which worked fine too, and AFAIK your code does exactly the same thing, so I don't really know why this happens... I tried to use '\r\n' and also '\r' instead of '\n', but that doesn't work correctly either. Uwe. -- Uwe Hermann <uh...@bi...> http://www.bingo-ev.de/~uh1763/index.html ----------------------------------------- :wq |
|
From: Brian S. P. <bst...@me...> - 2000-03-02 15:46:49
|
Uwe - What do you think of using glib's GStrings instead of c-strings in the URL structure? This would allow us to have dynamically sized strings for the url and buffer instead of arbitrarily sized buffers that are given hard limits at compile time. Let me know -- if you think this is a good idea, I'll work on changing it tonight or this weekend. If you don't like this, what would you think of changing the URL structure to use dynamically-sized buffers for the url and the buffer? -Brian |
