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?
Posted: January 20th, 2013, 11:57 PM
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.