Wedge

The plugin does what it says on the tin :)

Is the little envelope not flashing for you? Works fine installed here.

So I've been wrangling with this, and I don't see any way around what needs to be done for this.

Specifically, as nice as it is using Aeva, I don't believe that we can meaningfully use that on a production site, because there's a bunch of meta information that's required, not to mention the fact that the nature of private repositories requires providing a login and ideally without having to actually do the usual run of actually logging in.

Not to mention the nature of serving plugins and so on carries a performance hit that I'd rather not carry on the main server (especially as in the future I plan to have plugins query for updates and that's going to be expensive). We can use a subdomain if we wanted to, I also own wedgeplugins.com/.net/.org just in case.

So, let me explain the entire nature of the plan I have, and then we'll deal with questions.

I plan to run a separate plugin repo, on a separate Wedge install to here. This is to isolate performance issues. In fact, there's no reason why - with what I'm about to say - that it even needs to be on the same physical server. From a performance perspective it may even be better if it is not. I'll come back to this in a minute.

So, plugin server serves three types of requests from repos, it serves: simple list of plugins (be that in categories or otherwise), actually serving the plugin, and searching for plugins.

The architecture I have in mind will even allow for private plugins and so on, quite happily, the user provides their username/password when adding the repo. It sends the details when making a request as part of the request (in a very encoded form, of course), and authentication is done there.

As far as the 'separate server' gig, that's not a huge deal. Some people here will be familiar with the concept of IP.Connect; this is the principle plan I have, to use the second server as a slave using the IP.Connect protocol to connect to this site (this means you have two sites that have conjoined accounts in a sense)

Alternatively if third party sites want to set up their own repos, that's an option too.

Mechanically, we're talking about a plugin that accepts requests to action=plugins and handles the requests from there. Mostly that's straightforward requests, but here's the clever part: we can easily make this a complete 'mod site' as was, including comments/support, approvals or whatever and creating boards/topics as needed.

It just seems to me that doing it on a separate site is actually a stronger proposition than trying to manage it here in the long run, especially in performance terms. Given how much trouble people have with sm.org, it actually seems to me that having proper separation is actually more of an advantage than not separating it.

I'm also thinking this will help shift some of the 'perceived liability' especially if this other site becomes a sort of marketplace of sorts, which is ultimately where I hope to go with it.


Any questions?

I should add, it would not be terribly difficult for me to drop all repo handling and just leave it to people to browse the site etc. But this seems more professional to have it integrated. I would not lose *that* much sleep if the opinion were overwhelmingly against worrying about having integration into the core.

Most of this is stuff that needs to be done either way, though.

Nope, that's the point. While the table is being rewritten, it's locked from all other accesses. The point is that if you're modifying a huge table, you're going to be blocking access to all other concurrent accesses. The point of having it in maintenance mode is that it drastically cuts down on those concurrent accesses.

It's more about being a courtesy to users and cutting down the limit of how long it's going to take.

For most plugins, it's no big deal to do their installation, even down to creating new tables and so on.

But plugins that modify tables, especially if they're going to modify big tables that are heavily used (topics, messages, members), it seems to me that it might be worth enforcing the site is in maintenance mode before installing such (because the tables will be locked during that time)

I'm sort of torn on whether this is needed or not (though I think it is certainly useful), and though part of me is tempted to enforce it, I think what I'd rather do is leave it to the plugin author whether they want to use it.

What I'd do in that case is provide an attribute somewhere which indicates what action/actions require maintenance mode or not, for example, <plugin id="Arantor:plugin" maintenance="enable,remove-clean"> to mirror the possible scripts that something could run; typically only enable and remove-clean are the times this is an issue anyway since it is enable and remove-clean that invariably are schema changing.

Thoughts?

I seem to recall being the one who wrote the fun and exciting UNION query that fetched things, and it wasn't respecting pinned topics properly, but the latest commit should show it as fixed now.