#realy #devstr #progressreport
almost finished the abstraction of the publisher interface... the transport specific elements are now fully separated into their own packages and can now become part of the API libraries for websocket and http.
when this is done, it will mean i can later add more, like a TCP/QUIC api, for example, that will be like the websockets but with less of the http->websocket round trip that websockets require due to the upgrade
it also means that later it will be a lot easier to add a full new event encoding, much the same process as what i'm doing now except then adding an abstraction for the encoder
a little ways to go yet, but i'm on the home straight
the main difference that it will make is that where before the event publish is going through a mutex to add a subscription, it will instead just bump a return channel and context, and when the subscription gets a CLOSE it will instead just cancel the context and the publisher will iterate the subscriptions and delete the ones that have canceled context
much greater separation of concerns, the api libraries then have the publisher interface along with the method call interface, and become a unified, consistent API that probably can even be further abstracted into an interface, meaning that they can then be interacted with from the relay side without needing to refer to implementation specifics, and it will then be what Uncle Bob would consider "clean code"
it is usually ok if you don't have any intention to add new ways of interacting between two parts of your codebase, to not make interfaces, some people, like my friend from ireland who i worked with on indra, was of the opinion to make an interface immediately so that when you do realise you need to make more, different implementations of stuff, you don't have to refactor your code to accept the new implementation, and i think he's probably right about this
i'm cleaning up and refining someone else's code, written without thought for the future, probably because he is a grant chaser and not thinking about his work becoming a commercially employed technology, which is also why the API of nostr is such a nightmare to extend
for this afternoon though, i'm getting pretty much past the point where i can see myself finishing the last piece of this to make the common abstraction and eliminate the tight coupling, but tomorrow, now that i have teased apart the pieces nicely and started sketching out the publisher interface fully, the last part should just be a few hours work