From: James HK <jam...@gm...> - 2013-08-08 11:35:00
|
Hi, When I looked over SMWPageSchemas which is right now part of SMW core, I failed to understand as to why it has to be deployed with SMW core. I do not know the exact circumstances on how PageSchemas operates but the current design requires SMW core to deploy SMWPageSchemas for some reason. Normally when you deploy a class requiring it to derive from a different class that resides in another extension (SMWPageSchemas extends PSExtensionHandler ) it is because you expect that the concrete implementation is specific to the environment that implements this class, nevertheless when I tried to figure out which part of SMWPageSchemas is so specific that it has to be deployed with SMW core I failed. As for the reason why I failed, I could not see a clear dependency that would require SMWPageSchemas to be implemented by SMW core meaning no specific object injection occurs from SMW core into SMWPageSchemas that would allow to draw a conclusion about an inherent (or even necessary) dependency that can only be resolved by deploying it with SMW core. Other issue while browsing through SMWPageSchemas are: * All methods are declared static which makes it a less likely candidate to be testable * Mixing string manipulation using raw '<p>' , or XML::, Html:: which can potentially create issues with escaping * Each method relies on GLOBALS such as global $wgUser; global $wgContLang; etc. It would be nice to have some sort of resolution on how to deal with this class. In case it is decided that this class should remain in SMW core, a proper unit test should be provided (by PageSchemas) in order to minimize any vulnerability and exposure due to object references such as (PageSchemas::getValueFromObject etc.). PS: This is not about eliminating PageSchemas from SMW but rather to ensure that dependencies (and so its implementation) does reside within an appropriate context without exposing other objects to unnecessary risk. Cheers |
From: Yury K. <kat...@gm...> - 2013-08-08 11:49:49
|
Honestly I don't understand why do we need these dependency injections for such a task as form/property/template generation. I remember Yaron have explained that it's a legacy remained from some kind of global plan of making PageSchemas the central framework for managing all kinds of extensions. ----- Yury Katkov, WikiVote On Thu, Aug 8, 2013 at 3:34 PM, James HK <jam...@gm...>wrote: > Hi, > > When I looked over SMWPageSchemas which is right now part of SMW core, > I failed to understand as to why it has to be deployed with SMW core. > > I do not know the exact circumstances on how PageSchemas operates but > the current design requires SMW core to deploy SMWPageSchemas for some > reason. > > Normally when you deploy a class requiring it to derive from a > different class that resides in another extension (SMWPageSchemas > extends PSExtensionHandler ) it is because you expect that the > concrete implementation is specific to the environment that implements > this class, nevertheless when I tried to figure out which part of > SMWPageSchemas is so specific that it has to be deployed with SMW core > I failed. > > As for the reason why I failed, I could not see a clear dependency > that would require SMWPageSchemas to be implemented by SMW core > meaning no specific object injection occurs from SMW core into > SMWPageSchemas that would allow to draw a conclusion about an inherent > (or even necessary) dependency that can only be resolved by deploying > it with SMW core. > > Other issue while browsing through SMWPageSchemas are: > * All methods are declared static which makes it a less likely > candidate to be testable > * Mixing string manipulation using raw '<p>' , or XML::, Html:: which > can potentially create issues with escaping > * Each method relies on GLOBALS such as global $wgUser; global > $wgContLang; etc. > > It would be nice to have some sort of resolution on how to deal with > this class. In case it is decided that this class should remain in SMW > core, a proper unit test should be provided (by PageSchemas) in order > to minimize any vulnerability and exposure due to object references > such as (PageSchemas::getValueFromObject etc.). > > PS: This is not about eliminating PageSchemas from SMW but rather to > ensure that dependencies (and so its implementation) does reside > within an appropriate context without exposing other objects to > unnecessary risk. > > Cheers > |
From: Jeroen De D. <jer...@gm...> - 2013-08-08 12:18:35
|
Hey, I concur with James on the points he made. The approach taken would make more sense if SMW was a plug in to PS, as this is what the code makes it out to be. I'd rather see the code be part of PS, and have it only be registered there is SMW is loaded. Cheers -- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. ~=[,,_,,]:3 -- |
From: Markus K. <ma...@se...> - 2013-08-08 12:24:22
|
On 08/08/13 13:18, Jeroen De Dauw wrote: > Hey, > > I concur with James on the points he made. > > The approach taken would make more sense if SMW was a plug in to PS, as > this is what the code makes it out to be. I'd rather see the code be > part of PS, and have it only be registered there is SMW is loaded. +1 Markus > > Cheers > > -- > Jeroen De Dauw > http://www.bn2vs.com > Don't panic. Don't be evil. ~=[,,_,,]:3 > -- > > > ------------------------------------------------------------------------------ > 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 > Sem...@li... > https://lists.sourceforge.net/lists/listinfo/semediawiki-devel > |
From: Yaron K. <ya...@wi...> - 2013-08-08 13:24:48
|
Wow... I don't know if there's ever been such quick consensus on a topic on this list. Evidently that Page Schemas class has been bugging people for a long time. :) Yury wrote: > I remember Yaron have explained that it's a legacy remained from some kind of global > plan of making PageSchemas the central framework for managing all kinds of extensions. I don't recall ever having said that... not that I understand what it means. I'm not even sure what a "global plan" is. :) The idea with Page Schemas is that it's a framework for defining a data structure and generating the necessary pages based on that structure - but the specifics of the structure and the page-creation are defined by the set of extensions installed. Now, as was pointed out, all this logic could go into Page Schemas itself, but I think it's a nicer solution to have each extension provide its own logic: - Whenever an extension's data structure details change, it can take care of modifying its Page Schemas code on its own, ensuring that Page Schemas will always (up to a point) work correctly with the current installed version of that extension. - Each extension provides its own i18n messages for the extension-specific text it provides to Page Schemas - I think that's a much nicer solution than having Page Schemas hold a ton of messages that actually relate to the workings of other extensions. - New extensions that want to add their data structures into Page Schemas can do that, and further modify their code, without any coordination with me or whoever is maintaining the PS code at the time. Now, any approach to this kind of thing will have code-compatibility issues, so I shouldn't say that in this current approach the extensions will "always" work correctly together. If the Page Schemas API changes in any way, then of course the extensions' code will all have to change, which is a downside. But on the other hand, I think changes to the data structure are likely to happen on a much more frequent basis than changes to the Page Schemas API. My planned changes to the Semantic Drilldown extension, for instance, will require removing some fields from the Semantic Drilldown Page Schemas interface. This is not unique to Page Schemas, by the way - my Admin Links extension does the same thing, and SMW (along with other extensions) also has code specific to Admin Links. Or maybe I shouldn't have said that. :) And there are potentially other extensions that could use the same setup - like an extension that let you configure LocalSettings settings from the web interface. I think the Configure extension, which does that but holds all its settings in one place, would have been a lot stronger if it had used a hook-based system to let each extension define its important settings itself. -Yaron On Thu, Aug 8, 2013 at 8:24 AM, Markus Krötzsch < ma...@se...> wrote: > On 08/08/13 13:18, Jeroen De Dauw wrote: > > Hey, > > > > I concur with James on the points he made. > > > > The approach taken would make more sense if SMW was a plug in to PS, as > > this is what the code makes it out to be. I'd rather see the code be > > part of PS, and have it only be registered there is SMW is loaded. > > +1 > > Markus > > > > > Cheers > > > > -- > > Jeroen De Dauw > > http://www.bn2vs.com > > Don't panic. Don't be evil. ~=[,,_,,]:3 > > -- > > > > > > > ------------------------------------------------------------------------------ > > 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 > > Sem...@li... > > https://lists.sourceforge.net/lists/listinfo/semediawiki-devel > > > > > > ------------------------------------------------------------------------------ > 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 > Sem...@li... > https://lists.sourceforge.net/lists/listinfo/semediawiki-devel > -- WikiWorks · MediaWiki Consulting · http://wikiworks.com |
From: Jeroen De D. <jer...@gm...> - 2013-08-08 13:49:06
|
Hey, > Wow... I don't know if there's ever been such quick consensus on a topic on this list. Yes, you have won of badge of some sorts :) > I'm not even sure what a "global plan" is. :) Ah, of course you would deny your secret plans to take over the world, and then install SMW everywhere. > But on the other hand, I think changes to the data structure are likely to happen on a much more frequent basis than changes to the Page Schemas API. This might be true. However if you look at what is actually happening, nothing of this nature has changed since the introduction of the class. >From an SMW maintenance perspective, it is not nice to have this code in there. And having this "semi dependency" on PS makes things more fuzzy for both users and devs. A third option is to have a PSSMW extension that depends on both SMW and PS, and contains the code in question. This of course comes with its own set of tradeoffs. Presumably one such extension can be made to hold PS all code for SMW and SMW extensions. Cheers -- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. ~=[,,_,,]:3 -- |
From: Yaron K. <ya...@wi...> - 2013-08-08 14:53:25
|
Hi, On Thu, Aug 8, 2013 at 9:48 AM, Jeroen De Dauw <jer...@gm...>wrote: > Hey, > > > Wow... I don't know if there's ever been such quick consensus on a topic > on this list. > > Yes, you have won of badge of some sorts :) > > > > I'm not even sure what a "global plan" is. :) > > Ah, of course you would deny your secret plans to take over the world, and > then install SMW everywhere. > Well, it's true that I'm constructing a giant laser beam, but it's for, uh, research purposes only. :) > > > > But on the other hand, I think changes to the data structure are likely > to happen on a much more frequent basis than changes to the Page Schemas > API. > > This might be true. However if you look at what is actually happening, > nothing of this nature has changed since the introduction of the class. > That's true, although things do change - as I noted, there's a plan for the Semantic Drilldown structure to change sometime in the near future. And the SMW setup could potentially change as well. A big part of the reason why there haven't been any changes in the SMW class is that SMW doesn't do any page-generation itself - Semantic Forms takes care of some of the things that perhaps ideally SMW itself should hold, like the CreateProperty and CreateTemplate special pages. (That's a subject for another thread, though - I don't mean to derail this one.) So it's the SF PS code that changes if there's a change to the SMW data structure setup, like the recent removal of the "String" property. But if the helper forms for creating properties and/or SMW-based templates were to ever move to SMW, SMW's Page Schemas class would most likely start needing updates on any data structure change. Which I think is as it should be. > > From an SMW maintenance perspective, it is not nice to have this code in > there. And having this "semi dependency" on PS makes things more fuzzy for > both users and devs. > I don't actually see it as confusing or difficult, personally - I think it's a nice, modular approach to creating an interface that involves the behavior of a bunch of extensions. As I noted, Admin Links takes the same approach, and I don't think that one has caused any confusion (though perhaps I shouldn't keep mentioning it :) ). > > A third option is to have a PSSMW extension that depends on both SMW and > PS, and contains the code in question. This of course comes with its own > set of tradeoffs. Presumably one such extension can be made to hold PS all > code for SMW and SMW extensions. > Oh... adding another extension sounds like a worst-case scenario. Especially if the goal is to prevent user confusion... -Yaron > > > Cheers > > -- > Jeroen De Dauw > http://www.bn2vs.com > Don't panic. Don't be evil. ~=[,,_,,]:3 > -- > -- WikiWorks · MediaWiki Consulting · http://wikiworks.com |
From: James HK <jam...@gm...> - 2013-08-08 15:47:25
|
Hi Yaron, If we look from a point where we see SMW core being assigned to tasks like data storage, data access, or querying then the implementation of SMWPageSchemas feels a bit sidetracked to the point where: For example having code like [1] where $psTemplateField is some kind of an object but without specific type hinting it could be anything and its dependency is more than vague (from a SMW core point of you it is non-existent because any operation that happen an behalf of this object is unknown to SMW core). Which part of SMWPageSchemas is so specific to SMW that it requires SMW itself. As far as I understand SMWPageSchemas is mostly doing string/array manipulations like [2] of some sort but when it comes to property/value access it relies on [3] or [4], meaning that data access is not the issue. SMWPageSchemas acts as a formatter of raw values that PageSchemas can present to a "consumer". SMW core doesn't (and it shouldn't) know anything about formatting rules that are required by PageSchemas (of course now it does because of SMWPageSchemas). Nothing in the code points to a truly SMW core specific (data storage, data access, or query related) task that could not be done by a generic object formatter, so why does SMW core has to implement something like [5] when the only consumer of the code is the PageSchemas extension, making SMW core depending on PageSchemas for this specific class (and make it actual not testable because of the forced dependency). [1] $prop_array = $psTemplateField->getObject('semanticmediawiki_Property'); if ( empty( $prop_array ) ) { continue; } [2] $typeTag = "[[$hasTypeLabel::$propertyType]]"; $text = wfMessage( 'smw-createproperty-isproperty', $typeTag )->inContentLanguage()->text(); [3] PageSchemas::getValueFromObject( $prop_array, 'name' ); [4] PageSchemas::getValueFromObject( $prop_array, 'Type' ); $allowedValues = PageSchemas::getValueFromObject( $prop_array, 'allowed_values' ); [5] $html_text .= "Type: " . Xml::tags( 'select', $propertyDropdownAttrs, $select_body ) . "</p>\n"; Cheers On 8/8/13, Yaron Koren <ya...@wi...> wrote: > Hi, > > On Thu, Aug 8, 2013 at 9:48 AM, Jeroen De Dauw > <jer...@gm...>wrote: > >> Hey, >> >> > Wow... I don't know if there's ever been such quick consensus on a >> > topic >> on this list. >> >> Yes, you have won of badge of some sorts :) >> >> >> > I'm not even sure what a "global plan" is. :) >> >> Ah, of course you would deny your secret plans to take over the world, >> and >> then install SMW everywhere. >> > > Well, it's true that I'm constructing a giant laser beam, but it's for, uh, > research purposes only. :) > > >> >> >> > But on the other hand, I think changes to the data structure are likely >> to happen on a much more frequent basis than changes to the Page Schemas >> API. >> >> This might be true. However if you look at what is actually happening, >> nothing of this nature has changed since the introduction of the class. >> > > That's true, although things do change - as I noted, there's a plan for the > Semantic Drilldown structure to change sometime in the near future. And the > SMW setup could potentially change as well. A big part of the reason why > there haven't been any changes in the SMW class is that SMW doesn't do any > page-generation itself - Semantic Forms takes care of some of the things > that perhaps ideally SMW itself should hold, like the CreateProperty and > CreateTemplate special pages. (That's a subject for another thread, though > - I don't mean to derail this one.) So it's the SF PS code that changes if > there's a change to the SMW data structure setup, like the recent removal > of the "String" property. But if the helper forms for creating properties > and/or SMW-based templates were to ever move to SMW, SMW's Page Schemas > class would most likely start needing updates on any data structure change. > Which I think is as it should be. > > >> >> From an SMW maintenance perspective, it is not nice to have this code in >> there. And having this "semi dependency" on PS makes things more fuzzy >> for >> both users and devs. >> > > I don't actually see it as confusing or difficult, personally - I think > it's a nice, modular approach to creating an interface that involves the > behavior of a bunch of extensions. As I noted, Admin Links takes the same > approach, and I don't think that one has caused any confusion (though > perhaps I shouldn't keep mentioning it :) ). > > >> >> A third option is to have a PSSMW extension that depends on both SMW and >> PS, and contains the code in question. This of course comes with its own >> set of tradeoffs. Presumably one such extension can be made to hold PS >> all >> code for SMW and SMW extensions. >> > > Oh... adding another extension sounds like a worst-case scenario. > Especially if the goal is to prevent user confusion... > > -Yaron > > >> >> >> Cheers >> >> -- >> Jeroen De Dauw >> http://www.bn2vs.com >> Don't panic. Don't be evil. ~=[,,_,,]:3 >> -- >> > > > > -- > WikiWorks · MediaWiki Consulting · http://wikiworks.com > |
From: Yaron K. <ya...@wi...> - 2013-08-08 16:36:56
|
Hi, Well, I think you've reached the crux of the issue, which is the question of what exactly SMW should be in charge of doing and what it shouldn't. If you view SMW as essentially a library that provides "data storage, data access, or querying" for MediaWiki - sort of a MySQL for MediaWiki - then indeed having the Page Schemas dependency is not appropriate. However, I think it makes more sense to view SMW as an extension that provides a lot of support related to the storage and querying of data. I can think of a number of things that SMW does, unrelated to its core goals: - Helper pages like Special:Properties (though that arguably is part of core functionality) - RDF export of data - The "Powered by SMW" button on the bottom of pages - The #info tooltip function - Adding to the Admin Links page (maybe I really should stop mentioning this one) - Defining various things related to Semantic Forms - the "Form:" namespace, the "type" used by special properties like "Has default form". In addition, I think it could make some sense for SMW in the future to incorporate any of the following features currently in Semantic Forms: Special:CreateProperty, Special:CreateTemplate, #arraymap and #arraymaptemplate. None of those are of course necessary for SMW to function. 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). 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's true that the SMW Page Schemas class doesn't actually contain that much SMW-specific code (though certainly some of it is SMW-specific) - but, as I noted, that's really just an accident of history, based on the fact that creation of property pages and the like is done by Semantic Forms. If that ever changes, the code in the SMW PS class will look a lot more SMW-heavy. As for testing the code - it wasn't quite clear from the way you worded it, but I assume you're saying that this class is not testable, not that the presence of this class makes all of SMW not testable. Assuming it's the former, yes, it would probably require integration testing and not unit testing, but I'm sure it's all doable in theory. -Yaron On Thu, Aug 8, 2013 at 11:47 AM, James HK <jam...@gm...>wrote: > Hi Yaron, > > If we look from a point where we see SMW core being assigned to tasks > like data storage, data access, or querying then the implementation of > SMWPageSchemas feels a bit sidetracked to the point where: > > For example having code like [1] where $psTemplateField is some kind > of an object but without specific type hinting it could be anything > and its dependency is more than vague (from a SMW core point of you it > is non-existent because any operation that happen an behalf of this > object is unknown to SMW core). > > Which part of SMWPageSchemas is so specific to SMW that it requires > SMW itself. As far as I understand SMWPageSchemas is mostly doing > string/array manipulations like [2] of some sort but when it comes to > property/value access it relies on [3] or [4], meaning that data > access is not the issue. > > SMWPageSchemas acts as a formatter of raw values that PageSchemas can > present to a "consumer". SMW core doesn't (and it shouldn't) know > anything about formatting rules that are required by PageSchemas (of > course now it does because of SMWPageSchemas). > > Nothing in the code points to a truly SMW core specific (data storage, > data access, or query related) task that could not be done by a > generic object formatter, so why does SMW core has to implement > something like [5] when the only consumer of the code is the > PageSchemas extension, making SMW core depending on PageSchemas for > this specific class (and make it actual not testable because of the > forced dependency). > > [1] > > $prop_array = $psTemplateField->getObject('semanticmediawiki_Property'); > if ( empty( $prop_array ) ) { > continue; > } > > [2] > > $typeTag = "[[$hasTypeLabel::$propertyType]]"; > $text = wfMessage( 'smw-createproperty-isproperty', $typeTag > )->inContentLanguage()->text(); > > [3] PageSchemas::getValueFromObject( $prop_array, 'name' ); > > [4] PageSchemas::getValueFromObject( $prop_array, 'Type' ); > $allowedValues = PageSchemas::getValueFromObject( $prop_array, > 'allowed_values' ); > > [5] $html_text .= "Type: " . Xml::tags( 'select', > $propertyDropdownAttrs, $select_body ) . "</p>\n"; > > Cheers > > On 8/8/13, Yaron Koren <ya...@wi...> wrote: > > Hi, > > > > On Thu, Aug 8, 2013 at 9:48 AM, Jeroen De Dauw > > <jer...@gm...>wrote: > > > >> Hey, > >> > >> > Wow... I don't know if there's ever been such quick consensus on a > >> > topic > >> on this list. > >> > >> Yes, you have won of badge of some sorts :) > >> > >> > >> > I'm not even sure what a "global plan" is. :) > >> > >> Ah, of course you would deny your secret plans to take over the world, > >> and > >> then install SMW everywhere. > >> > > > > Well, it's true that I'm constructing a giant laser beam, but it's for, > uh, > > research purposes only. :) > > > > > >> > >> > >> > But on the other hand, I think changes to the data structure are > likely > >> to happen on a much more frequent basis than changes to the Page Schemas > >> API. > >> > >> This might be true. However if you look at what is actually happening, > >> nothing of this nature has changed since the introduction of the class. > >> > > > > That's true, although things do change - as I noted, there's a plan for > the > > Semantic Drilldown structure to change sometime in the near future. And > the > > SMW setup could potentially change as well. A big part of the reason why > > there haven't been any changes in the SMW class is that SMW doesn't do > any > > page-generation itself - Semantic Forms takes care of some of the things > > that perhaps ideally SMW itself should hold, like the CreateProperty and > > CreateTemplate special pages. (That's a subject for another thread, > though > > - I don't mean to derail this one.) So it's the SF PS code that changes > if > > there's a change to the SMW data structure setup, like the recent removal > > of the "String" property. But if the helper forms for creating properties > > and/or SMW-based templates were to ever move to SMW, SMW's Page Schemas > > class would most likely start needing updates on any data structure > change. > > Which I think is as it should be. > > > > > >> > >> From an SMW maintenance perspective, it is not nice to have this code in > >> there. And having this "semi dependency" on PS makes things more fuzzy > >> for > >> both users and devs. > >> > > > > I don't actually see it as confusing or difficult, personally - I think > > it's a nice, modular approach to creating an interface that involves the > > behavior of a bunch of extensions. As I noted, Admin Links takes the same > > approach, and I don't think that one has caused any confusion (though > > perhaps I shouldn't keep mentioning it :) ). > > > > > >> > >> A third option is to have a PSSMW extension that depends on both SMW and > >> PS, and contains the code in question. This of course comes with its own > >> set of tradeoffs. Presumably one such extension can be made to hold PS > >> all > >> code for SMW and SMW extensions. > >> > > > > Oh... adding another extension sounds like a worst-case scenario. > > Especially if the goal is to prevent user confusion... > > > > -Yaron > > > > > >> > >> > >> Cheers > >> > >> -- > >> Jeroen De Dauw > >> http://www.bn2vs.com > >> Don't panic. Don't be evil. ~=[,,_,,]:3 > >> -- > >> > > > > > > > > -- > > WikiWorks · MediaWiki Consulting · http://wikiworks.com > > > -- WikiWorks · MediaWiki Consulting · http://wikiworks.com |
From: Jeroen De D. <jer...@gm...> - 2013-08-10 06:26:22
|
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 -- |
From: Yaron K. <ya...@wi...> - 2013-08-11 13:48:36
|
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 <jer...@gm...>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 |
From: Jeroen De D. <jer...@gm...> - 2013-08-14 00:17:01
|
Hey, Yaron, I disagree with some of the points you made here. However taking a step back from this, perhaps its not worth bickering about what is really the best thing to do here if all else where perfect already. Though there is room of improvement here, it hardly seems urgent, and quite far down the priority list. So my vote actually goes for leaving it as it is, and concentrating on more critical todos. Cheers -- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. ~=[,,_,,]:3 -- |