💾 Archived View for bbs.geminispace.org › u › zzo38 › 20915 captured on 2024-12-17 at 15:02:00. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
Multi-protocol browser (Dschubba)
Dschubba is intended to be a multi-protocol browser for use with X windows
in GNU/Linux systems.
It is FOSS, and is not written much yet; part of the decision of how to
make up the data structures and a few other things.
Goals (not all of them are first priority, though; some would be later):
Non-goals:
Some things are undecided so far, and some ideas might be changed later
before they are actually implemented. (Also, other people are allowed to
(try to) help if they wish, or to criticize it, etc)
Oct 16 · 2 months ago · 👍 mrrobinhood5, clseibold, thewanderer · ❤ 1
Good luck! It's quite a journey. What stack are you planning to use? And are you thinking of a normal windows/tabs system or something else?
🦂 zzo38 [OP] · Oct 16 at 18:53:
C, Xlib, OpenSSL. (I also already wrote some stuff for dealing with URLs (which I also used in the "astroget" program) and with ASN.1 DER.)
A normal system with windows is probably my intention. Tabs is probably not something I will consider; the window manager could handle tabs.
Why not make something useful instead of a kitchen sink? Sorry to be a downer, but what you propose is something that its guaranteed to do at least one key task poorly enough to be useless. As an example, I would never buy a coffeemaker with a built in grinder as at least one will suck or break and I will have to toss it.
It's the opposite of the Unix way.
🦂 zzo38 [OP] · Oct 17 at 23:20:
There are many things it is specifically intended not to do (some of which I listed; I also specifically said probably I would not have tabs, since that should be better handled by the window manager instead). Of course, it will not do everything (e.g. it is not intended to send/receive email). And, other programs (especially web browsers) are guaranteed to do other things badly; it is not specific to this one only.
Furthermore, much of the pieces are intended to be modular (by designing it with good data structures), and not everything will be done within the same program itself (external programs that can be configured by the user to do some things too). But, like with UNIX you can use multiple programs together with pipes etc, also this one some things can be done using separate programs with it too.
The scope is less than that of the web browser, but perhaps as much as Lagrange and some things, but there are some different ideas. Furthermore, not everything will be implemented all at once.
If there are specific features that you specifically do or do not want, or that you think should be included or excluded regardless of what you specifically want a program to do, then please mention these things, too. And, if you can be specific about which specific things I had proposed, you have a criticism of, then please mention that, too.
Firstly, it's your life and if you think it's fun to do whatever you want to do, it is certainly not my job to stop you. I have a bunch of (likely not well informed) opinions that you are free to ignore.
The scope of a web browser is insanity; half of one is correspondingly half of that...
LaGrange is a very, very large project, and I am amazed it works as well as it does. I don't know many people who could pull it off.
Leaving tabs to the OS may be actualy a mistake, as you will have to build full context for each one, which may be too much work for the user. In addition, without communication multiple browsers in multiple tabs will not be aware of some information which they should be. This arbitrary decision may not be a wise place to start cutting on functionality. Just as an example.
What I am trying to say is that I am not objecting to most of what you propose, but you propose a bunch of arbitrary goals. Whether they are sensible, I certainly don't know, and I don't know if you do either.
Are you proposing to remake Lagrange with a lot of features removed and supporting a couple of extra protocols?
P.S. If you do want to make something like you described, may I suggest creating a few serously decoupled components: a general-purpose multi-document GUI framework which accepts simple plug-in networking and rendering components. The interface should be C -- not ideal but you can build a foreign interface for any language. It should be easy to make one for the TUI and the console too. And consider user information management - certificates, bookmarks, history, how it works across protocols, etc.
But then again, I've never seen something like that done well, and it is a very hard project (an order of magnitude harder than writing a browser). Why not pick something "small", like a really good misfin client, and do it well?
🦂 zzo38 [OP] · Oct 19 at 03:49:
Thank you for your opinions.
What I am trying to say is that I am not objecting to most of what you propose, but you propose a bunch of arbitrary goals. Whether they are sensible, I certainly don't know, and I don't know if you do either.
It is true, I don't know for sure. However, not all of the goals are meant to be done immediately, some will be implemented earlier and some will be later, and some goals might change later if necessary.
Are you proposing to remake Lagrange with a lot of features removed and supporting a couple of extra protocols?
Kind of, I suppose; however, many things are different principles than Lagrange has doing. It is meant to be a separate program like there are many other implementations of Gemini, Gopher, etc, it is not meant to be only one kind of implementation that all does things in the same ways.
There are things about Lagrange I dislike, such as:
(Note: I do not use Lagrange.)
If you do want to make something like you described, may I suggest creating a few serously decoupled components: a general-purpose multi-document GUI framework which accepts simple plug-in networking and rendering components.
Actually, it is (almost) my intention.
I will have to figure out the data structures to use. So far, I had considered to have:
I would think that I would need more, too, such as:
Actually, I don't know if more will be needed than that, or if any of this is more than what will be needed.
There is also the question to know what functions and other fields to put into each object.
I have some ideas, and may write another message after this one (although that should not stop you from replying to this one before I do so, if you have any replies to write).
The interface should be C -- not ideal but you can build a foreign interface for any language.
I like the C programming language. It is not perfect, but the other ones are worse in many ways, in my opinion.
Also, that does not necessarily mean that a foreign interface will work well (for many reasons, mainly having to do with the working of the interface of other programming languages), but I have no intention to support anything other than C anyways, so perhaps that does not matter as much.
It should be easy to make one for the TUI and the console too.
This is possible too, although it is not really my intention; the rendering code will be specific to X window system, I think.
And consider user information management - certificates, bookmarks, history, how it works across protocols, etc.
OK, it is a good point. However, I think that certificates, bookmarks, and history, can work in mostly the same way regardless of protocols and file formats.
But, how other things will work across protocols, is the issue, although if I define a abstract interface for this then hopefully it will work.
But then again, I've never seen something like that done well, and it is a very hard project
Well, I do not intend to do absolutely everything.
Nevertheless, I do intend to do some things, and should not necessarily have to be one person alone to do it, I should suppose.
Why not pick something "small", like a really good misfin client, and do it well?
I could, and it would be another idea. I do not really intend to implement Misfin, and if I do, it would be outside of the scope of this program and will be a different one.
Also, I might not want to require OpenSSL; there are other implementations of TLS and maybe the stuff to deal with TLS can be one file that it can be changed.
OpenSSL is rather confusing. One thing I could not figure out is how to handle raw certificates when receiving and validating server certificates. (BearSSL seems to do it, but BearSSL does not have TLS 1.3 so far as I far as I know.)