Wedge

Hehe, well I recently had a 'debate' with others about "everyone being on FB" and "G+ being a ghost town"... I'm honestly not fussed either way.

Heh, reminds me of the hellspawn hasLayout hacks for IE...

Technically, I remember when there was only one plugin, heh... :P

Facebook page is still live, if a shade quiet because we've been busy coding (see Facebook.com/wedgebook)

I don't believe there's much holding us up from releasing a visible demo to people, but a downloadable version is still a bit away, I think, knowing that there's at least one fairly big bug in the admin area at present.

For me, I've spent most of my time the last month working on the plugin system, which is usable and working (there are at least 3 plugins I know of, one of which is a port of SimpleDesk) if it's still WIP, though early indications suggest it's going to work out well :)

I don't have a problem with this, but I'd rather make it an admin preference to list the people who want them instead...

phpseclib is the SSH/SFTP library in pure PHP. I figure if I can get it small enough, I can justify including it into the plugin manager for handling permissions changes on hosts where FTP isn't an option. It's 600KB to kick off, I was down to about 400KB without having to trim too many of the comments by general cleanup, and if I strip all the comments, I can get it down to probably 250KB.

I don't really envisage having to update it very often, which is advantageous if it's bundled, and I can fully sympatheise with your issues with getID3.

The old package manager could put slahses into the URL when browsing a package server. The language editor shouldn't but you never know, and I'm not sure about the skin selector. It isn't common, though, not at all - it's sufficiently rare that you could remove it and we'll fix anything that gets broken in consequence.

No, I don't think it does, and even if it did, it'd be bloody slow.

OK, so today I've been working on a DTD for the plugin XML format, to describe what it should contain and in what order.

The real question I've been wrangling with is whether I should enforce the order of things in the file, e.g. <hooks> can contain 1+ function tags, 1+ language tags and 0 or 1 provides tags. Now, in my example files and all my own files, I've always put functions first, then language files, then provides tags.

Now, the parser itself doesn't care too much, it's built to be more forgiving, but I'm thinking that it shouldn't be so forgiving, that having a set process/standard will encourage better behaviour than being more forgiving, so that I'm thinking about the DTD validator being more strict.

So, for example, I wouldn't have it enforce the order of most tags, but stuff like <hooks>, I'd enforce the order like that.

Thoughts?


Disclaimer: there is a secondary reason for doing it like this: it's actually a pain in the arse writing a DTD that has rules where there are mandatory tags and optional tags, and that there isn't a set order because you have to define all the possible permutations.[1]

1.	Like the DTD definition for the HTML head tag, as it has to state a mandatory title tag, an optional base tag and 0+ optional other tags, and that's still a multi-line definition through a %entity replacement.