26th December 2017 — Adrian Cochrane

Planning internal Trait Framework

While I wait for Odysseus to be accepted into the AppCenter (which is probably understandably slow during the Holiday season), I thought it might be nice to lay out a short-term roadmap for an internal framework to develop longer-term (though very important) browser features on.

Where Am I Now on this?

I already have the start of an internal framework for traits, as they have been a crucial help in delivering the traits I’ve already developed. Specifically this framework consists of:

Notably the templating language so far has only been useful to aid more internationalization and to render the viewsource page. But it’s trivial to see it’ll be vital to later developments and for whenever I find a way to render my own error pages without overwriting those of sites like GitHub that don’t specify ahead of time the filesize of those error messages.

What Do I Want To Add to This?

In large part I want to be able to make greater use of Odysseus’s database from internal pages:

But also I want a more intelligent addressbar which stretches a bit beyond the native Gtk.Entry control to allow:

Then to allow fast detection of whether to show particular icons, I want “services” to make it fast to trigger the presentation of icons upon certain:

Once the data is lexed by a Vala library, a simple HashMap should help prevent any slowdown whatsoever (that is no matter how many MIMEtypes or RDF predicates I test for, the performance would remain the same). Particularly if I can do these tasks on idle.

Browser Extensions

I am very hesitent to support browser extensions, because as they are implemented in the mainstream browsers they mostly serve to slow the browser down whilst cluttering their toolbars. However as I move towards helping my surfers to find webpages to visit, it’ll become hard for me to do so without utilizing arbitrary third-party datasources. These datasources would amount to a type of browser plugin, one I (and WebKit) can optimize better whilst having enough control of their UI to make them invisible navigation aids.

Currently I plan to support to support the following types of extensions:

Notably, (almost) all of these extensions correspond to existing standards with the exception being content blockers. But that’s an existing format from Apple that’s already in use. Furthermore, for simplicity, these would be installed during the course of normal browsing through icons in the addressbar. Upon install, a toast overlay would confirm successfully install and, to support AppCenter-style pay-what-you-want/koha payment models, include a button linking to a donation page if it can find one. To do so it would like for a link with a rel=payment, which in turn is another existing “microdata” standard.

@ 2017-12-26 16:52:38 +0000

Talk Page for Internal Framework Plans — Odysseus Development Blog