Review of links 0.84
Linuxcare has published a review of links as part of its App of the Week column.
Read the review!
Keep up the good work, Mikulas!
Now Links just needs to support aalib for rendering graphics :P
Conversion html to text
with lynx I can type
$ lynx -dump doc.html > doc.txt
to do subj. Will links ever have such possibilities?
cookies and authentication
since mikulas isn't interested in doing it, would anyone be interested
in adding cookie support to links? sorry, but it's required for some
sites i visit (and i don't mind).
more importantly, when will links support authentication? i had to
use w3m to sign in to post this comment. :)
Lynx & wb0 fusion -- useful at all?
Look at wb0 announce which will come soon. Do you mean that it is
worth of effort to try to weld Links and wb0 together? I think the images are relatively wanted even by hackers and that browsers
that typeset the images into the text will never run fast. So my idea
is to display the image after a click on a text link for it. But do it all in graphics mode, because loading external viewer is a half-solution. Also, the grx mode removes the problem with
Why I wrote Links
There have been questions why to write Links instead of improving Lynx and W3M. Links and Lynx have absolutely different programming style. Links uses callback mode to manage most actions - when we want to (for example) make connection, we call function make_connection and pass pointer to functions that will be called when the connection is ready. make_connection registers request and returns immediatelly. (Netscape does it the same way). In contrast Lynx and W3M use blocking calls for many actions - they call make_connection, it waits until connection is done and then returns. As a result, Links easily manages more simultaneous connections. Lynx and W3M don't and _never_ will.
Lynx will never have features like continuing loading page even if user selected 'Back', downloading files in background, preloading documents, revalidating cache in background. Links will.
Joining Links and Lynx is hard. They can reuse html parser and table code in Lynx, but the core is completely different.
Good work Mikulas!
Wokan wrote: "Does it have very different goals from the Lynx program? ". So what? Does gnome project have very different goals from kde project? What's wrong with too many text editors? There are many people with different preferences so there IS a need for different programs that have same goals. Here rules natural selection. If some program is not used and people doesn't like it then it probably dies. I have been playing with "links" for last few hours and I like it very much - for me it is better than lynx.
Keep on going Mikulas.
Because it's a complete re-write?
I suspect one reason for the split is that this is a complete re-write from scratch, not just a few hacked in additional features. The code size is claimed to be considerably smaller than lynx... something you don't get by just adding features in a "fork".
Sometimes a complete re-write is a good thing to flush out heaps of evolutionary cruft. At the same time, the older app is usualy more "mature", and still deserves consideration because of this. Merging the work on two totaly different implementations like this is nearly impossible and counter-productive in any case.
Normaly I agree with the sentiment that it is better to contribute to an existing project than create another one (how many text editors are there?), but in this case I think there is room for two text web browsers, and lynx is probably getting a bit long in the tooth.
Why a parallel project?
I'm just wondering why this project was started. Does it have very different goals from the Lynx program? Couldn't this table and keepalive support been added to Lynx instead of starting a new browser?
I'm all for having choice in browsers, but in this case, the two are so close in nature, it seems silly to have them seperate.
An open, cross-platform journaling program.
A scientific plotting package.