Posts in category "Python"

The work to add Titan support to Rogallo is going well, and I've been able to test it out fine on bbs, doing additions of "long text" and performing file uploads. In doing so, though, I was reminded that there is a proposed "edit" extension to Titan, which is supported there (and I believe on a couple of other capsules too). That got me thinking...

Wasat v1.9.0 is now available, which adds support for this extension. Of most use is the is_edit property which has been added to TitanURI, giving a well-defined approach to testing whether a Titan URI is for editing a resource. The Client class has also grown an edit method to handle the request for the raw content which will then be used as the basis for a subsequent edit by the user, before being uploaded.

All of this, of course, pushes back the work I'm doing on Rogallo, just a little. As I said above, the Titan support is pretty much there and working, but now I want to try and really dial it in and get it working "just so". While the edit support is probably pretty niche, it seems worth adding and, I hope, might delight someone one day when they try it out and it "just works".

Another quick little update to Wasat, bumping the version to v1.8.0. This version is in support of some work I'm about to do on Rogallo: Titan support.

This release adds TitanURI and makes a number of changes to handle such URIs alongside GeminiURI. A lucky side-effect is that a problem was uncovered and corrected with how Gemini URIs are sliced and diced in the library. This first showed up for me when I was having a look at the Scriptonite examples. None of them were working for no obvious reason. Eventually it became clear that parts of the URIs were being lost as they travelled through Wasat's code.

So v1.8.0 clears up that problem (fixing the bug in Rogallo by simply upgrading the library).

As of now, I can move on to actually adding Titan support.

I've just released the first version of another library in the collection of libraries that support the development of Rogallo: specifically, another one that helps convert text in other formats into Gemtext so Rogallo's display can be a little richer. In effect, this is a sibling to md2gemtext and html2gemtext.

This time it's a library to convert finger responses into Gemtext, where it makes sense. For the most part, finger responses are free-form plain text, but there are times when there's information in the response that would be of most use if you could interact with it. For example, if you get a user list from plan.cat¹, that's a lot of data that could be turned into finger:// URIs that can be subsequently followed.

With this in mind, finger2gemtext can take a body of text, look at it to see if it might be possible to convert it to useful Gemtext, and will convert it if that's the case. Given that there's no standard to be had here, and given that any given response could be of any form the author desires, I'm making the conversion pretty conservative.

What I have done, though, is make it so that the conversion process can be extended. The finger_to_gemtext function can be given a collection of additional filtering classes; if the built-in classes can't find anything to convert, the additional classes get a go. There is a base class to inherit from.

I've not fully planned it out yet, but the vague idea I have here is that Rogallo could, at some point, have "finger plugins" which will handle various special cases and site-specific formats.

For now, though, this gives me the basics that let me turn this:

into something where I can follow finger:// links without the need to copy/paste/edit:

Now I need to find a few more online finger resources that respond with things worth making linkable...

A small update to Port79, bumping up to v1.1.0. This release adds a resolve method to the FingerURI class.

I'm currently tweaking Rogallo's rendering of some responses from finger services and being able to resolve URIs relative to the underlying page is going to be very helpful.

A quick little update to Wasat, bumping the version to v1.7.0. In service of a feature I'm adding to Rogallo, I've added a forget method to the trust store class, so that a certificate fingerprint for a particular host/port combination can be forgotten.

This came about because, if a fingerprint does change for a Gemini capsule, I want a Rogallo user to be able to decide to either avoid it or forget it and re-establish trust. While the fingerprint mismatch should be a warning to distrust the capsule, there might be a legitimate reason why the certificate has changed, and I want to make that decision fairly frictionless.

While it might seem that it's been pretty quiet on the Rogallo front the past few days, I've been doing some work on it every day. There are a lot of changes and improvements coming. As I got the next release ready, I realised that some of the support libraries I've built for it were stuck with 0.x versions while, at the same time, having proven to be quite stable.

So I've just made v1.0.0 updates to the following:

• html2gemtext
• md2gemtext
• port1900
• sybaritic

There are no material changes in any of these releases, the only real change being the bump to v1.0.0, and so marking them as stable and, of course, guaranteeing that semantic versioning promises are now in place.

The client certificate management PR for Rogallo is very close to completion now -- although the thing has grown arms and legs and turned into a bit of a UI overhaul¹. Something I wanted to add was a quick and easy way for the user to view the details of a client certificate that's being used for the current page. Rogallo lets you do this for the server certificate, but not the client certificate.

It was at this point that I realised I'd never provided easy access to the ClientCertificate on the Response object. So v1.6.0 addresses this and provides Response.client_cert.

With this in place, I think I can finally get that Rogallo PR over the line...

I'm still working on the client certificate management PR for Rogallo, which, of course, heavily leans on the API of Wasat. In most cases, I've noticed that something I want to do in the PR can already be done, but the work to perform the action would seem like unnecessary detail in a client application; I want to make using Wasat as frictionless as possible.

With this in mind, v1.5.0 adds interfaces for exporting and importing client certificate data.

Another bump to Wasat, this being v1.4.0. This release is in support of some work I want to do on Rogallo, where I intend to add proper client certificate management.

While Wasat provided good support for the generation, storage, and use of client certificates, there was no real public API that would allow for the management of those certificates. This version addresses that.

Now there are methods for doing things like:

• Listing all client certificates
• Getting a specific certificate's details
• Creating a certificate
• Associating and disassociating a certificate with a URI
• Deleting a certificate

This should give me everything I need to implement a simple client certificate user interface in Rogallo.

I've just made a small update to BagOfStuff, my little support library for my personal Python-based FOSS projects. This release makes some more changes to the history classes, adding an add_or_replace method, and also making some improvements to the type hinting by basing the classes on MutableSequence rather than Sequence.

While the history classes were originally intended to feel immutable, it's obvious that they're really not. The idea was that stuff gets added to them, stuff falls off the other end, and stuff might disappear depending on the context and when stuff gets added. The general idea was that direct manipulation was something that wouldn't happen. So I'd started out with them inheriting from Sequence, and so implying they were a read-only interface.

Given this acknowledgement, they now inherit from MutableSequence. This means that some extra (dunder) methods are added, and it also means that some extra exceptions can be raised. For example: setting slices to iterables isn't supported and will raise a NotImplementedError. Some other slice-based operations aren't supported either.

While this is close to a breaking change, it's fine for my use of this code. However, I had to make one big breaking change: I'd written clear so that it returned Self¹. The interface expected by MutableSequence is one that returns None. So to strictly comply with that interface, I've changed the return type.

With this being a breaking change, I've bumped the library version to v2.0.0. While it's really a small change, and only one I'd notice, there's no getting away from the fact that the API has changed. That deserves a major version bump.