Weboob.org got me thinking and I came up with an idea based on the principles
With this idea, we will be dividing and limiting what "categories" of web pages
can exist. For each category of a web page we will have a dedicated program to
handle it. So it's basically like Weboob, where we have a few programs and
those interface to services.
We don't however write modules to support different websites in the sense
Weboob does, we create API's that dictate what is possible for each category
and for each category we create a dedicated program to handle it. Website
developers will have to implement those specific API's to allow the programs to
interface with them.
This is an interesting idea. One thing the Freenet Project has done is provide
a simple interface to generate "Freesites". If you provide developers an easy
way to create their site, some might actually do so.
* less freedom for web developers, as they have to abide by category API and
don't have much room for customizations unless specifically allowed for by the API
* we _need_ to either heavily modify or write our own programs to make this work
I would assume only those who are interested in the project itself would create
sites, like i2p or Freenet developers write for their project out of interest
for the project itself. Others may not see any reason.
I actually _really_ like this idea.
It's very interesting!
Posted on Rocksolid Light
And once you are done
That will take a while :). Still working out the specifications, but I have already started working on a prototype. I'll share my progress once I have it in a somewhat pre-aplha state.
don't forget to include an api for federation to news servers. :-)
Yeah, I'm planning to add federation support to the forum server when I get there. Rocksolid uses NNTP to federate, correct?
Posted on RetroBBS
-----BEGIN PGP SIGNED MESSAGE-----
I have already started working on a prototype
I've called it "Lean".
Overall I'm not too pleased with it, but more on that later.
To give a quick overview, I've implemented:
- - A binary format specification called LDSF (Lean Data Serialization
Format) and implemented a library with property tests in Haskell
- - A protocol called Lean, a stateless binary protocol that uses the
binary format LDSF
- - A Haskell library called lean-client which is a simple to use client
implementation of the Lean protocol
- - A browser called Lean
- - A handler for the category "text" which gets embedded seamlessly into
the browser (ascii file viewer which highlights links such as
lean://example.i2p/text/some_text_file.txt and makes them clickable)
One thing I'm really not happy about is the delay introduced by launching
the handler programs. e.g. when you browse to
"lean://crowbar.i2p/text/test.txt", it knows it has to launch the program
lean-handler-text because of the /text/ in the URL to handle it, but the
delay of starting a GUI program is not insignificant and therefore quite
This delay is especially prominent on single board computers, _even_ if
the handler program is written in _plain old C_. A GTK+ or Qt GUI program
simply takes a bit to start up and there isn't much one can do other than
pre-launch that program and let it idle around. It currently uses around
3-4MB private memory for the browser and around the same amount per
handler. So the RAM usage per tab would be around 3-10MB depending on the
content and handler.
Right now, because I haven't implemented a "real" server yet, the browser
just acts as if it would be corresponding with a server. This is so that I
can test the interactions between the browser and the handlers, which is
the most important bit right now.
I did not expect embedding would be such a pain in the ass and quite
messy. Getting it working reliably on multiple window managers on Linux is
probably going to be a real nightmare.
I've attached the source code.
There's a a README.md file in there that explains how to build it.
Currently it only works on GNU/Linux with X11. It's only a prototype,
don't expect things to actually work properly. No idea if I'm going to
continue with this.
cabal new-build lean lean-handler text
cabal new-run lean
then type into the url bar: lean://crowbar.i2p/text/test.txt
-----BEGIN PGP SIGNATURE-----
-----END PGP SIGNATURE-----
Posted on RetroBBS
thats some cool shit, my dude. i thought you would spent more time on the specs.
Thanks. Specs are far from complete, ultimately I want to specify everything, remove all ambiguity and write them in RFC-format. This is mainly to see if it is any good in practice.
concerning the loading: you could try to select (and recommend to your users) a set of programs which are very lightweight and quick. Could be something ncursed based for the text part, for example. and those who prefer to use bloatware hopefully have the machines and the ram for it.
This is a good point, ncurses based UI would be extremely fast and also very usable with this design. I still want to make a GUI version that is extremely fast on single board computers if possible. I have a few ideas I will be testing.
Posted on RetroBBS