Symphony.

Here's a first draft. https://gist.github.com/1078271

Nice. Maybe we should keep localisation of the description in mind and make it look something like this (allowing multiple description elements):

<description lang="en">Index text content of entries for efficient full-text search.</description>

Yep, good suggestion, updated. The compatibility stuff in my example needs improving. I think the current release version/date should be merged with compatibility into a single "releases" list.

Another thing: what about requirements/dependencies?

I think the current release version/date should be merged with compatibility into a single "releases" list.

Why don't we merge release and compatibility into a single element?

Good idea, please add. I presume you mean SSM/Stage? Not sure how to link extensions together since they don't have a unique identifier. Perhaps their Github URL could act as a unique ID, when marking dependencies.

I presume you mean SSM/Stage?

Haha – I actually forgot about that. I thought of JIT that is needed for most image previewing extensions.

Releases + compatibility: https://gist.github.com/1078346

Sweet. A more succinct version could be:

<release version="1.9" date="2011-07-01">
    <compatibility>...</compatibility>
</release>

Should other repo types be supported? <repository> is being used to point to the Github page and not the repository itself. A repository element needs two URLs, one for the homepage and one for the clone URL, but maybe that's over-complicating when you can determine the clone URL from the Github page URL anyway.

Also, an <author> could also have a Github or Symphony site username element.

I know we like XML, but if Symphony will have to parse XML for each extension then it will be taking longer time than it does now (with instantiating extension).

If that XML is to be used just by "extension repositories", then i guess it is ok. But if you want to make Symphony use that too, then i think it is a really bad idea.

Extensions are PHP, so why not have meta.php file? Or about.php? It is easy to include, and probably much easier (and thus faster) for PHP to get data from it.

We're only talking about the Extensions page in the backend, right? Symphony doesn't need to access the about() meta information in any other place. So during a page lifecycle it won't need to touch the XML file. Even if you have 50 extensions installed, I'll reckon that opening and parsing 50 short XML files won't add more than a second to that page load.

nickdunn, thanks. I still think that PHP would be better in this case, but if you say that it's only Extensions page that will be slower, then i guess it is a low price for easier implementation of "extension repositories" in future.

How about we try it in a separate branch and then we'll know for sure. Nothing to lose at this stage, if .xml doesn't work out, at least we've got a solid reason for it rather than speculation :)

I didn't read up on the entire discussion, so maybe this has already been discussed, but is it an idea to also add tag repository location to a release?

This would make it possible to implement an automatic installment of previous and future versions of extension from the Administration interface.

That's a good suggestion, linking directly to the tagged release. One of my worries is the way in which we use Github URLs. Do we use the repository "homepage" on Github (the root of the repo browser), or do we use the clone URL?

<repository type="git">https://github.com/nickdunn/search_index</repository>

Here I've used the homepage of the repo browser. You can't provide a deeplink (so to speak) to a tag within the clone URL itself (unlike with SVN), so the tagged release URL would look like:

https://github.com/nickdunn/search_index/tree/0.9.1

To this end, do we say that all URLs should be the repo browser pages in Github and not clone URLs? You can programmatically parse the clone URL from a Github URL very easily.

In fact, you can build the URL to a tagged release if you have the repo stub and the tag name. That would negate the need to physically paste the URL into the XML file.

I added a <dependencies> element:
https://gist.github.com/1114078

This does rather remind me of Maven POMs ;-)

Another thing that we should iron out — what is an extension's homepage? Sometimes we link to the Github repo, other times to the forum discussion, other times to the extension page on this site.

What I'm finding, as people move everything to Github, is that the pages on this site are becoming less useful. When I need an extension I go straight to Github and search.

So if in these meta files we provide an extension <homepage> or <url>, should the convention be to use the Github URL? This means the user can omit the <repository> URL as they are the same thing.

In this way, a Github URL becomes the extension's unique identifier in defining dependencies and such. What are the alternatives? Use the extension name as a string (the directory name it installs within), or the numeric ID from this site.

Similarly what about names of people. I use the same handle on this site as I do on Github, so for me it makes sense for me to be represented nickdunn. The URL to my profile can be built on both sites. But in a list of contributors, presumably via Github, should we use full names, Symphony profile names, or Github usernames? And should these be linked to the person's person site, their profile here, or their Github profile?

Wordpress have a very strict standard, for example:

• "Contributors" is a comma separated list of wp.org/wp-plugins.org usernames
• "Tags" is a comma separated list of tags that apply to the plugin
• "Requires at least" is the lowest version that the plugin will work on
• "Tested up to" is the highest version that you've successfully used to test the plugin. Note that it might work on higher versions... this is just the highest one you've verified.
• Stable tag should indicate the Subversion "tag" of the latest stable version, or "trunk," if you use /trunk/ for stable.

But they try to be a very self-contained ecosystem, whereby listing a plugin requires you to use the SVN repo they provide for you.

Am I overthinking this?

What if we allowed a generic <url> element and then a type attribute? We can define the available types (or the whole schema) and developers can choose from the available types. A similar thing could be done for author, adding a github and symphony to represent the handles.

example:

<author>
    <name github='nickdunn' symphony='nickdunn'>Nick Dunn</name>
    <email>nick@nick-dunn.co.uk</email>
    <website>http;//nick-dunn.co.uk</website>
</author>


<url type="repo">https://github.com/nickdunn/search_index</url>
<url type="homepage">http://nick-dunn.co.uk/search_index/</url>
<url type="wiki">https://github.com/nickdunn/search_index/wiki</url>

It could be a more flexible solution instead of creating different/adding extra elements, which IMO is more verbose.

What if the same URL was to be used for each? Could you write it once and make the one element repo, homepage and wiki to reduce repetition?

On the gist Nils (phoque) commented:

I'd suggest using AppID's/ExtensionID's to identify extensions and dependencies. So instead of

<dependency>https://github.com/nilshoerrmann/stage</dependency>

I'd use

<dependency>com.nilshoerrmann.symphony.stage</dependency>

Or whatever ID he'd be using.

Could you explain a bit more the rationale behind this? The namespacing doesn't look like a convention we're using already, so I'm keen not to invent something new.

I think many App-ID implementations use that reversed domain model (at least the three big mobile OS-es do so) so I just went with what I was used to. :-)

Granted, they'd work just as much as real URLs, the issue I see when using real URLs as unique application identifiers is that they're not really useful in that context (at least not more useful than a reversed domain).

What value should be picked if an author doesn't have a website or a GitHub account? Also what happens if the URL changes or becomes invalid?

A reversed domain could also include other information, like the version number com.nilshoerrmann.symphony.stage/1.2.0 (don't know if that makes much sense though)

Well... the rational behind it in Maven is that it allows you to have a very clear convention on how to identify a dependency:

GroupID: com.symphony-cms ArtifactID: someextension Version: 1.0.0

would generate the Unique location of http://url-to-extension-repository/com/symphony-cms/someextension/1.0.0/

In that directory, by convention, you place an about.xml file which can be fetched and parsed. In that file you can have sub-dependencies which can be downloaded automatically as well.

It's really a good system, but perhaps it's a bit too much for Symphony?