This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
1801
Features / Re: New revs - Public comments
« on January 23rd, 2013, 03:27 PM »
Don't you mean "byte me" in reference to Android icon? :lol: I shouldn't try to be funny after only just having breakfast.
Also, yes, it will all go, I did think of removing the log table last night but saw it had at least two references and couldn't be arsed chasing them down last night.
Also, yes, it will all go, I did think of removing the log table last night but saw it had at least two references and couldn't be arsed chasing them down last night.
1802
Archived fixes / Re: Linktree
« on January 23rd, 2013, 03:24 PM »
Looks good :)
Could use a touch of space between the bottom link tree and the footer, and perhaps a bit of space between the top tree and the menu, which dropping the dotted border on the menu.
Could use a touch of space between the bottom link tree and the footer, and perhaps a bit of space between the top tree and the menu, which dropping the dotted border on the menu.
1803
Plugins / Re: Plugin server
« on January 23rd, 2013, 03:14 PM »
It is a bit more than that, you have a master and 1+ slaves, where the slaves look for a local account and failing that query for the master, and create an account, plus keeping them in sync when there are password changes. Having a separate server within the same subdomain doesn't solve auth issues, as such, since the second install still has to cope with dual DB stuff. The only way around that is to run it off this server, which for stated reasons I do not want to do.
I did buy wedgeplugins.com etc just in case but I'm not averse to plugins.wedge.org.
Of a plugin server, very little of it is actually related to the files themselves. All the effort is around metadata, stuff that Aeva not only doesn't need to do, but should never have to even consider. In theory I could solve it by making Aeva drastically more hook able but that's not really the point either. I'd still need to write a ton of handling anyway. The workload is about the same in either case. I do not expect to find much, if anything, in the way of improvements on top of Aeva with this stuff.
I did buy wedgeplugins.com etc just in case but I'm not averse to plugins.wedge.org.
Of a plugin server, very little of it is actually related to the files themselves. All the effort is around metadata, stuff that Aeva not only doesn't need to do, but should never have to even consider. In theory I could solve it by making Aeva drastically more hook able but that's not really the point either. I'd still need to write a ton of handling anyway. The workload is about the same in either case. I do not expect to find much, if anything, in the way of improvements on top of Aeva with this stuff.
1804
Off-topic / Re: Plugin user interfaces
« on January 23rd, 2013, 03:05 PM »
I'm intending to have a vetting process, yes.
And yes, I can imagine there would be some collaboration, though I did.add some small features that would help.
And yes, I can imagine there would be some collaboration, though I did.add some small features that would help.
1805
Features / Re: New revs - Public comments
« on January 23rd, 2013, 02:54 PM »
I'm getting there!
1806
Features / Re: New revs - Public comments
« on January 23rd, 2013, 02:25 PM »
Almost nothing gets cached anyway.
I can't just blindly remove everything because other parts still use it! Do a search on read_tgz and see what you find...
Yes even Aeva uses it...
I can't just blindly remove everything because other parts still use it! Do a search on read_tgz and see what you find...
Posted: January 23rd, 2013, 02:25 PM
Yes even Aeva uses it...
1807
Features / Re: New revs - Public comments
« on January 23rd, 2013, 02:14 PM »
No because there is still code referencing it, and not just in the upgrader.
It will all be going soon enough!
It will all be going soon enough!
1808
Features / Re: New revs - Public comments
« on January 23rd, 2013, 02:04 PM »
Passing an array should not be significantly more expensive than passing a scalar variable.
And yes, stuff I haven't removed yet may still have some small use.
And yes, stuff I haven't removed yet may still have some small use.
1809
Plugins / Re: Plugin server
« on January 23rd, 2013, 06:00 AM »You're thinking of how frequent plugins should be checked for updates eh? I think it should simply look at version number, or hashed version number (e.g. alpha -> 2c1743a3)
The alternative is for a plugin server to say what plugins it has and their versions and then the local Wedge install queries for what it wants to update.
For small deployments, this isn't a problem. It only becomes a problem when it scales to SMF size, when you're into the multi-MB territory for plugin listings. (The XML file that indicates 'New Feature' plugins on sm.org is a 1.1 MB file listing the hundreds of plugins) Now, I can mitigate it somewhat, but it isn't going to be pretty. There's also potential issues in terms of memory use while doing this.
This is why, interestingly enough, WP only really allows for its own repo, specifically to avoid the privacy issue of reporting what plugins are installed on a server.
1810
Plugins / Re: Plugin server
« on January 23rd, 2013, 05:15 AM »Yes, an external url to their own demo of course. It would be very sloppy if hosted on that server. On that subject, there should be:
1. external url
For paid for plugins...
You should enable third party (user/password) to connect to your server using an automated script to store a key or something. Like this:
a942-b302c5b0d-1d75fa8-95f9e3d-7de-7c
I can't prevent nulled copies getting out there. It sucks, but it's true. It's not hard to find nulled copies of anything if you try.
On the other hand, I really don't want to get into the rabbit hole of licence key activation for the simple reason that it can and will put legitimate people off. As it is, InvisionPower marks my IPB test site inactive periodically and I have to go and re-validate my licence with them. Not even kidding >_<
It is my belief that it actually limits people unnecessarily more than it prevents piracy. In any case, no support without valid licence. And that's easy enough to deal with as it comes up, just as it is on sm.org with pirated DzinerStudio - ask them why they're not asking for support on the DS board. And lock it when it inevitably becomes clear.
As far as licensing goes, I already figured how I intend to do it. The idea is that you save the username and password in your forum (and they're hashed, of course) for your account on the plugin server, and then your install contacts the plugin server, providing authentication details, and the list of plugins you get back is what you have on your account.
Other stuff, like auto checking plugins for updates... not yet figured out how best to do that.
1811
Off-topic / Re: Plugin user interfaces
« on January 23rd, 2013, 04:47 AM »
So, encourage rather than beat them with a big stick. I can probably manage that :niark:
1812
Plugins / Re: Plugin server
« on January 23rd, 2013, 04:26 AM »
There's two versions of Aeva - Aeva Lite, and Aeva Media. Aeva Lite is purely the embedder, Aeva Media is the full gallery as well - and both are built into Wedge. Aeva is what has been used here thus far to serve the alphas and all the plugins we already wrote.
The plugin repo site will be similar in a number of ways to SMF's mod site, but with a few other... twists... in mind that will likely be pretty much unique to the main site.
Demo is a bit trickier to pull off, because ain't no way I'm giving out admin access to the admin panel to access things ;) But I can well imagine there being a link to a site where you can see it.
I should add, some of the plugins on the site I have in mind will be paid-for plugins. Exactly how that's going to work, I don't know yet, but that's what's going to happen, e.g. some of the bigger and rarer-used packages I have in mind will be paid-for plugins. But I'm building the add-plugin stuff to allow for repositories where you have to provide a username/password combo anyway.
The plugin repo site will be similar in a number of ways to SMF's mod site, but with a few other... twists... in mind that will likely be pretty much unique to the main site.
Demo is a bit trickier to pull off, because ain't no way I'm giving out admin access to the admin panel to access things ;) But I can well imagine there being a link to a site where you can see it.
I should add, some of the plugins on the site I have in mind will be paid-for plugins. Exactly how that's going to work, I don't know yet, but that's what's going to happen, e.g. some of the bigger and rarer-used packages I have in mind will be paid-for plugins. But I'm building the add-plugin stuff to allow for repositories where you have to provide a username/password combo anyway.
1813
Plugins / Re: Plugin server
« on January 23rd, 2013, 02:01 AM »
Hmm, I think I went too big at once. Most of the plugin stuff is going to be fairly similar in nature to SMF's package server mechanically, the authentication side is almost just a sideline in a lot of respects.
The only things that really need discussion are:
1. Using/not using Aeva, though I think I made my position on that fairly clear
2. Creating a separate physical site to handle plugins and so on. Don't know if you've seen sm.org's comments about being busy, but a vast amount of their time/effort is actually spent handling plugins, serving plugin listings etc. for users, and the package parser and it's all attached to the main database there.
I believe having a separate physical site will mitigate the load considerably.
The only things that really need discussion are:
1. Using/not using Aeva, though I think I made my position on that fairly clear
2. Creating a separate physical site to handle plugins and so on. Don't know if you've seen sm.org's comments about being busy, but a vast amount of their time/effort is actually spent handling plugins, serving plugin listings etc. for users, and the package parser and it's all attached to the main database there.
I believe having a separate physical site will mitigate the load considerably.
1814
Off-topic / Re: Plugin user interfaces
« on January 23rd, 2013, 01:26 AM »
Hmm, maybe, but if you're not up to creating even a modest UI, how much of a plugin are you writing anyway?
1815
Off-topic / Plugin user interfaces
« on January 23rd, 2013, 01:05 AM »
Is it just me or do plugin authors generally write fairly poor user interfaces for their plugins/mods?
I know I did a few times, but usually because of keeping it straightforward to integrate into the ACP and minimise manual edits, but when I stretched my legs with SimpleDesk, I spent a fair amount of time writing a decent admin UI and I think it shows the effort that went into it.
Am I being overly cynical or are a lot of plugins lacking decent UI? Is this something we should try to discourage in Wedge?
I know I did a few times, but usually because of keeping it straightforward to integrate into the ACP and minimise manual edits, but when I stretched my legs with SimpleDesk, I spent a fair amount of time writing a decent admin UI and I think it shows the effort that went into it.
Am I being overly cynical or are a lot of plugins lacking decent UI? Is this something we should try to discourage in Wedge?
* Arantor has absolutely no restrictions about forcing plugin authors to produce decent user interfaces ;)