I think, before bundeling any extensions, there could be something like a compatibility check. Wordpress for example has something like this, and even allows to install plugins directly. So I think something like a compatibility and dependency check would be better. But on mediawiki side, not especially for SMW.
Am 17.07.2012 um 00:18 schrieb Yaron Koren <ya...@wikiworks.com>: > Hi Jeroen, > > I don't think this is a good idea as you've described it. It would certainly > increase convenience, for all the reasons you mention. But on the other hand, > it would automatically set up a "two-class system" for extensions: those that > are grouped in with Semantic MediaWiki, and those that aren't. In some cases, > this wouldn't be controversial: I think everyone would agree that Semantic > Result Formats is the right extension to use if you want to display semantic > data in charts, calendars and the like, and that Semantic Maps is the right > extension to use if you want to display it in map form. However, there are > various cases where it's not so obvious: for instance, Semantic Watchlist > provides notifications about changes to SMW data, but there are two other > extensions that, at least in theory, can be used for the same thing. And the > Semantic Image Input extension provides a useful input for Semantic Forms, > but there are various other extensions that provide just one or two form > input types: what are the criteria for deciding which of them get included > and which don't? > > There are some technical issues as well: you didn't include the Validator and > Maps extensions in that list, even though they're required by SMW and > Semantic Maps extension, respectively; presumably because there are people > who would want to install those without installing SMW. But at that point, > the whole thing starts to feel a little like a hack. > > Let me make a counter-suggestion, then: the Semantic Bundle package already > does essentially the same thing, of holding a curated group of extensions. Is > it possible to make a Git repository for Semantic Bundle, that just holds > symbolic links (or whatever the term is) to all of its extensions, in a way > that can be downloaded all at once, either via Git or as a tar file? That's > essentially what happens with Semantic Bundle already, although the SVN part > of it doesn't work that well. Maybe with Git it can function better, given > Git's greater flexibility. > > Tied in with that, maybe it makes sense to upgrade Semantic Bundle to a > recommended download solution for SMW, so that, for instance, instructions on > how to get it are right on the SMW download page, instead of on a linked > page. That seems like a good idea to me, though others might disagree. > > -Yaron > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Semediawiki-devel mailing list > Semediawiki-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
smime.p7s
Description: S/MIME cryptographic signature
------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
