Coming in iOS 3.8 is in app password change and registration. Password changing works but needs some better UI feedback.
May 24, 2019
Jérôme Poisson
SàT progress note 2019-W21
Hi,
this week has seen a bit of work on the website (mostly porting pages from the older one), and again the time to work on the project was short.
When your work on your free time, any moment you take for yourself (a week-end outside, reading a book/newspaper, watching a movie, having a drink, doing sport, etc.), or for the "things which must be done" (cleaning house, administrative things, fixing stuffs, etc.), or simply when you are sick, is time lost for the project, and it goes quickly. I'm living in such spirit for more than 10 years, feeling remorse for everything taking time, and it's not healthy or even sane, not for your nor your loved ones. And even in your project itself, there are a lot of stuff you have do to around it (server administration, website, documentation, communication – like progress notes –, keeping up to date with technologies, etc.) which are not directly improving the software.
I'm explaining this for you, the reader, to understand why it takes so long to develop a project, and why it can get on nerves. You can see now with the progress notes, that the release is nearly ready but still I've had little time to fix issues, and I wont be able to have everything perfectly oiled for this release.
Last week I've mentioned Pubsub, so let's move to this topic.
I won't elaborate on Pubsub itself, just for short Publish/Subscribe is a way to store/get data and to be notified when there are changes. You can see my talk at last FOSDEM (mp4 version) for some use cases. It is notably used in XMPP for blogging, i.e. for the "social network" part of it, and in SàT for events, tickets, merge requests, forums, etc.
During implementation of blogging features in SàT, years ago, the Pubsub implementations in XMPP servers were uneven, and mostly incomplete (because it was not needed for chat which most of the clients were focusing on). There was two options to work around that: choose a server with a working implementation, focus on it and recommend it, that's what have done Jappix and Movim with Metronome, or create a server agnostic component. We have chosen the latter with SàT, and have created "SàT Pubsub", a server independent implementation of PEP/Pubsub, which aims to be the most complete possible.
I've had to write and propose 2 XEPs (XEP-0355 and XEP-0356) to make this possible, but I'll pass the details to avoid making this post too long. Also, this would have hardly be possible without the work of Ralph Meijer which made the base Pubsub implementation in its library Wokkel that we use in top of Twisted, and Idavoll that SàT Pubsub derivate from.
So we now have an independent Pubsub implementation where we can implement everything we need without having to wait for every server to follow some new XEP. And even today when XMPP servers implementations have improved a lot, SàT Pubsub has some unique features, can follow novelties quickly, and is a good place for experimentation. I don't think all server implementations can be on a par with that, at least in the close future.
With that background explained, I'll now explain what I've worked on this week. In standard Pubsub (XEP-0060) when you have the suitable right, you can publish an item (a blog post for instance) with an existing id, this will create a new item and delete the one which was existing previously. But if we have a node where many people can publish, like a blog comment node, that means that anybody can replace the comment of anybody. So if Louise has written something, Pierre can replace the comment, not great.
In some pubsub implementations, which is the case for SàT Pubsub, you can't overwrite an item if you are not the publisher of this item, except if you are admin or owner of the node. That's better regarding blog comments, but there is still an issue: if Louise is owner of a node, and overwrite an item of Pierre, to modify something, she become the new publisher of the item, and Pierre can't modify it anymore. This is notably a problem with tickets: if Pierre report a bug, and Louise changes its status (e.g. because she starts working on the ticket), she becomes the new publisher, and Pierre can't edit it anymore).
To work around that, I've added a new node option which can be activated in configuration, "consistent publisher", which will keep the original publisher even if the item is overwritten (updated) if the entity overwriting the item is owner or admin. I've also prepared an option in database to restrict the maximum number of items in a node, but it's not implemented yet. I can now safely change status of reported issues for SàT without loosing initial publishers.
This week the post was longer than usual, I'll try to keep it shorter next time. As usual, feedbacks are welcome.
