Hi,
I didn't know whether you were serious about splitting off the SMW PS class
into its own extension, but clearly you are - and you might want other
functionality split off as well, like maybe an #info tag extension. I don't
know whether it's worth having a full discussion about the philosophy of
extension size on this list - there was a long discussion about this topic
on the wikitech-l mailing list last month that covered the main points,
which anyone can see here:
http://www.gossamer-threads.com/lists/wiki/wikitech/375342
This is a big topic, but I'll just say that the view of MediaWiki
extensions as libraries or packages is, in my opinion, not an accurate
description. If there were a true "package management system" for
MediaWiki, that everyone could use easily, it might be a different story,
but at the moment there isn't. So many people end up maintaining many
different versions of MediaWiki and many different combinations of
extensions, each with their own versions; and the more extensions there
are, the more work it is for admins and the more things that can go wrong -
and by extension, the more work it is for developers who have to document
all the installation steps, detail all the version compatibility issues,
and help with debugging every time something goes wrong.
But, back to this specific issue: what exactly is the liability of having
this PS SMW class/file contained in SMW? You and James have both said that
it would cause problems, but I don't see how. Even in the worst case, where
the code in the class is awful and doesn't work at all, as long as it
doesn't affect the normal running of SMW it shouldn't be an issue for SMW
developers. If you see a bug report or email relating to the SMW PS code
not working, you can either ignore it or assign it to whoever is
maintaining Page Schemas (at the moment, sending it to either me or Yury
would be fine). Is it really an issue that one or more classes in SMW are
not covered by unit tests, other than an aesthetic one?
-Yaron
On Sat, Aug 10, 2013 at 2:25 AM, Jeroen De Dauw <jeroended...@gmail.com>wrote:
> Hey,
>
> > I can think of a number of things that SMW does, unrelated to its core
> goals:
>
> SMW core could indeed be more lean.
>
>
> Now, maybe the right solution is to split off all of this extra stuff into
>> one or more other extensions, as was done with DataValues (and perhaps with
>> Diff and the rest - I don't know if those started out as SMW code).
>>
>
> Diff is not related to SMW in any way.
>
> DataValues is based on SMW code though not yet used directly by SMW. That
> is something planned though.
>
>
> > Personally, though, I think the better solution is to just view SMW as
> an extension that does a lot of things, in the back-end and interface,
> related to the storage of semantic data.
>
> It is important to differentiate between the developer and the user views
> on this. From a development perspective it makes a lot of sense to have
> these things nicely kept separate.
>
> From a user perspective certain combinations of packages tend to be
> desired. This is why software tends to have a build process, so the
> selection of functionality needed by the user can be put into an easy to
> use bundle that appears to be one piece of software to the user. And since
> different users have different needs, you'd typically have a few variants
> of this. For instance "SMW core" with just the core stuff, "SMW plus forms
> and related stuff", and "ALL of the SMW things". Right now we are not doing
> an as good job at providing such things as we could. SB is a step in the
> right direction, though still far from what we could have.
>
> From a dev perspective it is important to keep district things separate,
> to avoid not needed dependencies creeping in, and to reduce maintenance
> costs. Since we have not all that much manpower for maintenance, we should
> be very careful about this.
>
> Some factors that are relevant in determining if something should go into
> SMW core are size and code quality. In case of the Admin Links hook, which
> is just a few lines of simple code, there is not all that much reason to
> move it out. There is more PS code though, and it is more complex. Plus it
> has design issues which combined with the lack of tests make it a liability.
>
> In the case of the PS code, I'm not convinced that having a "PSSMW"
> extension would be to much of an issue even without improving our current
> build and publishing process. After all, there are many much smaller MW
> extensions out there.
>
>
> Cheers
>
> --
> Jeroen De Dauw
> http://www.bn2vs.com
> Don't panic. Don't be evil. ~=[,,_,,]:3
> --
>
--
WikiWorks · MediaWiki Consulting · http://wikiworks.com
------------------------------------------------------------------------------
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
_______________________________________________
Semediawiki-devel mailing list
Semediawiki-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
