I agree that the current design is less intuitive than it might be. The issue is legacy support - making sure thousands of older Fossil databases continue to function with their existing schemas even after new capabilities are added.

It comes down to this: There are USERS and there are SUBSCRIBERS. USERS have a login. SUBSCRIBERS get email notification of things. A single person can be a USER without being a SUBSCRIBER, or she can be a SUBSCRIBER without being a USER, or she can be both.

Users have a login-name and a password. The concept of a USER is an old one that has been in Fossil from the very beginning. The set of USERS for a repository is held in the USER table.

A subscriber merely gets email notification. Subscribers do not have a password or a login name. They have only an email address that big random hash that appears at the bottom of each email they receive. Subscribers are tracked by the SUBSCRIBER table which is new and does not exist in older repositories.

It is difficult to extend the USER table to cover the subscriber information. It would be relatively easy to add new columns to the USER table using ALTER TABLE ADD COLUMN. But the USER table content is also propagated using the "fossil config pull user" and similar commands, and the wire protocol for that command is not designed to be easily enhanced, unfortunately.

Also, it is easy to envision repositories that want to keep a distinction between users and subscribers. Users are people who have authorization to make changes to the code, contribute to wiki, or tickets, etc., whereas subscribers are the more numerous consumers who merely read the content generated by others.

So that is the origin of the problem. I have checked in changes today that attempt to simply the interface a little. Perhaps things will be less confusing now.

It comes down to this: There are USERS and there are SUBSCRIBERS.

I believe this issue is orthogonal. The same GET handler could handle all of the cases:

1. If you GET /subscribe as a non-USER, present a form showing the SUBSCRIBER's current subscriptions. If no subscriptions, show all boxes unchecked, so they don't just close the screen, thinking they're already subscribed.

2. If you GET as non-Admin USER, show the same screen, again defaulting to all-unchecked if there are not yet any subscriptions. The cookie will tell the POST handler whether it's dealing with a USER or a SUBSCRIBER.

3. If you GET as Admin, display the current contents of /subscribe in Admin mode. If they click "My Subscription", re-fetch the page with a query parameter that gives them the same page as for case #2 with values for the Admin's own user record.

The POST handler is the same for all cases, differentiating the cases based on query parameters, hidden fields, and/or cookie values.

The resulting C code will not be as pretty, but I think making the URL scheme pretty counts for more when it's exposed to the user.

(Contrast API URL schemes, where optimizing for the back-end code is appropriate, since the URLs are most likely being called by another program.)

I'm not particular about whether /alerts or /subscribe wins. The main thing is that I shouldn't have to go through the algorithm in my head to work out whether I should tell people to go to /alerts or /subscribe.

I'm giving these URLs in my docs because my current Fossil skins don't expose a Subscribe button in the navbar because I don't have the space for it, within my current self-impose limits on page width.