Wedge

Good instincts. This padding works tons better in Warm. Will commit in next batch.

rev 1870
(2 files, 2kb)

! Forgot to upload the Homepage in last commit. (Home.template.php)

* Tweaked Android icon to be less squarey and easier to see. It uses 5 more bytes... Bite me. (android.gif)

I can't think of anything that would be against adding this option, so yeah, why not..? :)

rev 1869
(15 files, 21kb)

* Doing my share to help with the packman removal... So, removed log_packages-related code. Also silly comments. (readme_install.html, readme_update.html, readme_upgrade.html, sphinx_config.php, smfinfo.php, upgrade.php, upgrade.sql, install.sql, Class-DBPackages.php, PackageGet.php, Subs-Package.php, extra.rtl.css, mana.css)

+ Added Home language files and fixed Homepage to match what you're seeing on Wedge.org right now. This mostly allows me to keep the file out of its 'ignore' changelist, which is a bit confusing to me. (Home.template.php, Home.english.php, Home.french.php)

- IPS Connect: I'm aware of this technology but am not sure how it works, especially when it comes to security. Doesn't this amount to simply transmitting authentication data between two servers...?

- Having another server for it: it doesn't prevent us from putting its data into 'plugins.wedge.org', for instance. A nice place to look at... Also, it potentially fixes cookie issues, although I liked the idea of having subdomain-specific cookies, allowing for cookieless subdomains to be designed. Although I guess it's better suited for a specific extra domain like 'wedgecdn' or whatever...

- Using AeMe or not: unsurprisingly, I'd push for the use of AeMe, if anything because I can help improving the software as well (I haven't touched it in a long time, but just because I'm rusty doesn't mean I can't be efficient with it). What's the alternative? Using SSI? To me that's mostly a waste of our valuable time if we have to rewrite a complete file server when we already have something good with AeMe, *and* it gives up an opportunity to improve AeMe's download system as we find new bugs or limitations by using it to distribute plugins.

Hope I didn't forget anything... I'm not very well versed in plugins as you know, so I tend to shamelessly avoid anything with the name 'plugin' in the topic title... :-/

Oh... Are you sure?I didn't mean to remove these functions anyway... I was mostly talking about anything directly related to packages.
For instance, do we really need to keep functions like parsePackageInfo (never called anywhere), parse_path (only used in parsePackageInfo..), packageRequireFTP (never used), package_crypt (only used in packageRequireFTP and create_chmod_control, which I'm not sure we need at all?), or listtree (never used)?
These are the functions I noted as 'deletable' in Subs-Package, in addition to listInstalledPackages...

Re: parse_bbc, ideally we'd get rid of everything but smileys (because these are pretty much in every function call), but I don't know what structure would work best for the cache ID... For instance, array('cache' => $id_msg, 'member' => $id_member) would be odd in a Display message parser, because that should most likely be array('id_msg' => $id_msg, ...) and parse_bbc should determine what elements are in the array and build the cache id from that... But it's slower, I guess.

So.. I don't really have any ideas to make it better right now. :-/

Re: log_packages, I can assure you I removed everything and it didn't take long... I'll double check.

That's the thing, $cache_id has always been used in a strange way... (Even re: original Aeva.)

So, the only thing that could stop us is performance. But I don't think passing an array has any impact whatsoever on performance... Does it?

Also, can I assume you're planning to remove everything related to packages, now? Your latest commit looks like it. I'm working on it right now and would like to know for instance if you want me to keep the package server code, or if you want to reuse it for plugins, or something like that...