Hello
We have had a pretty productive week with the Wikidata team. The most pressing issues concerning the Foundation team are however still the same:
The Sites table is pending finalization. It coming along nicely, and I think we will have a new version early next week. Development is happening on a separate development branch called "sites", any feedback is appreciated.
The Wikidata branch with the ContentHandler and related changes has seen some improvements over the week, and I have once more merged the latest master into the branch. However, I'm wondering how to best proceed now.
Until a few weeks ago, I let development on that branch rest, awaiting feedback so I could be sure to be moving into the right direction. This didn't work out, since the code was still too incomplete for a full review. I have now tied down most loose ends, but I'm still getting no feedback. Would it be best to halt development again? It's never going to be *finished*, there's always *something* to improve...
Cheers Daniel
On 01/09/12 06:08, Daniel Kinzler wrote:
Until a few weeks ago, I let development on that branch rest, awaiting feedback so I could be sure to be moving into the right direction. This didn't work out, since the code was still too incomplete for a full review. I have now tied down most loose ends, but I'm still getting no feedback. Would it be best to halt development again? It's never going to be *finished*, there's always *something* to improve...
I've been busy, but I can do another review of the ContentHandler branch this week. I'm not expecting to find major architectural issues with it. Architecturally, it's pretty simple: replace text with Content objects, and have a ContentHandler hierarchy representing their types. That basic scheme is not disputed.
There's the question of what level of quality we should aim for. We'll probably find things that will break when a non-text content type is used. I'd like to see such issues solved, or at least make sure the ContentHandler API will support a solution without major changes, but my reasons are mostly aesthetic. In principle, such development work can be done after the merge. But it seems to me that there's no point in merging it if it only supports text content, since MediaWiki already supports pure text content well enough. If we can achieve robust support for non-text data types, then the motivation for merging it will be stronger.
-- Tim Starling
Hi Tim!
For some reason, your mail went under my radar until now. Sorry about that.
On 03.09.2012 03:30, Tim Starling wrote:
I've been busy, but I can do another review of the ContentHandler branch this week.
That would be great, thanks!
There's the question of what level of quality we should aim for. We'll probably find things that will break when a non-text content type is used. I'd like to see such issues solved, or at least make sure the ContentHandler API will support a solution without major changes, but my reasons are mostly aesthetic. In principle, such development work can be done after the merge. But it seems to me that there's no point in merging it if it only supports text content, since MediaWiki already supports pure text content well enough. If we can achieve robust support for non-text data types, then the motivation for merging it will be stronger.
I agree. We are using the mechanism extensively for Wikidata, which of course uses non-text content. That should serve as a pretty good test. I'm trying to fix any issues I find on the road, but of course we are not exploring every possible corner of MediaWiki.
I think we should make sure that the main functionality of MediaWiki works with the ContentHandler without a hitch, and try to have sane failure modes for stuff that is not yet (dis)covered. There's no way to be 100% sure, of course.
This week, I have only done a little maintenance on the Wikidata branch (like merging master again). I'll be looking for loose ends some more over the next couple of days, but any changes should be confined to small corners of mediawiki. I'm using gerrit for all changes now, so you should be able track what i'm doing (well, last week I had to resort to a direct push when gerrit got very confused about a merge).
Thanks again Daniel
Just an idea, but wouldn't Lua source code make a perfect alternative content type?
2012/9/7 Daniel Kinzler daniel@brightbyte.de:
Hi Tim!
For some reason, your mail went under my radar until now. Sorry about that.
On 03.09.2012 03:30, Tim Starling wrote:
I've been busy, but I can do another review of the ContentHandler branch this week.
That would be great, thanks!
There's the question of what level of quality we should aim for. We'll probably find things that will break when a non-text content type is used. I'd like to see such issues solved, or at least make sure the ContentHandler API will support a solution without major changes, but my reasons are mostly aesthetic. In principle, such development work can be done after the merge. But it seems to me that there's no point in merging it if it only supports text content, since MediaWiki already supports pure text content well enough. If we can achieve robust support for non-text data types, then the motivation for merging it will be stronger.
I agree. We are using the mechanism extensively for Wikidata, which of course uses non-text content. That should serve as a pretty good test. I'm trying to fix any issues I find on the road, but of course we are not exploring every possible corner of MediaWiki.
I think we should make sure that the main functionality of MediaWiki works with the ContentHandler without a hitch, and try to have sane failure modes for stuff that is not yet (dis)covered. There's no way to be 100% sure, of course.
This week, I have only done a little maintenance on the Wikidata branch (like merging master again). I'll be looking for loose ends some more over the next couple of days, but any changes should be confined to small corners of mediawiki. I'm using gerrit for all changes now, so you should be able track what i'm doing (well, last week I had to resort to a direct push when gerrit got very confused about a merge).
Thanks again Daniel
Not really much different from the CSS/JS cases we already have.
The trickier stuff will be non-text stuff. Or especially the 'multipart' stuff as the [[ContentHandler]] page calls them.
It would be nice to have a test case where WikiText is part of a multipart type that also store things like a high-level list of categories (even though it will be an empty list). Just to make sure that basic functionality is not depending too heavily on pages being non-multipart.
On 07.09.2012 12:29, Daniel Friesen wrote:
Not really much different from the CSS/JS cases we already have.
Except that the current handling of CSS/JS is an inconsistent mess of special cases in various places of the codebase :)
The trickier stuff will be non-text stuff. Or especially the 'multipart' stuff as the [[ContentHandler]] page calls them.
We havn't implemented multipart content, and don't plan to. Multipart stuff is an interesting use case, but not on the Wikidata road map.
It would be nice to have a test case where WikiText is part of a multipart type that also store things like a high-level list of categories (even though it will be an empty list). Just to make sure that basic functionality is not depending too heavily on pages being non-multipart.
Well, the use case we currently test with Wikibase is all pages in the data namespace being non-text. That should cover this, no?
-- daniel
On 07.09.2012 12:22, Denny Vrandečić wrote:> Just an idea, but wouldn't Lua source code make a perfect alternative
content type?
Yes, it would, but it's also a textual content type. These are rather unproblematic. One thing that is not yet implemented is a highlighter interface for different kinds of code as content model.
Non-text content that mediawiki already uses: * gadget definitions * sidebar definition * license list for uploads * book sources * list of templates that indicate a disambiguation * etc...
Would be nice to convert some of them to actual non-text content models, just for testing. I don't want to commit to that at the moment though, I doubt I'll find the time.
-- daniel
wikitech-l@lists.wikimedia.org