Re: [Libreplanet-dev] Fwd: fsf groups extension patch

[John Sullivan]

(Your reply didn't keep the list in -- adding it back again, and leaving
the full text quoted here so others can see)

Peter <address@hidden> writes:

> On Friday 27 March 2009 20:19, you wrote:
>> (Can you make sure when you reply that you keep the list in?)
>>
>> Peter <address@hidden> writes:
>> >> Hm, okay. I'll have to think about this more; part of what we are trying
>> >> very hard to avoid here is custom code. We want to stick as closely as
>> >> possible to the Mediawiki upstream, so that we can continue to be
>> >> current and take advantage of all the extensions that are out there. Is
>> >> there any possibility of getting these functions added upstream?
>> >
>> > The custom code fits into the extension system provided by mediawiki. So
>> > it shouldn't be affected by upgrades. It is a standard wiki with custom
>> > extensions. I haven't tried to get the extensions 'officially' approved
>> > (like the calendar) because as you point out, its not really the
>> > mediawiki way.
>>
>> Wouldn't it make more sense to package these up as extensions and get
>> them distributed along with other extensions? That way, other people
>> might contribute to maintaining them, and they would at least have a
>> chance at being part of the upgrade path. I'm sure the extension system
>> changes from time to time and breaks things?
>
> Yes, but so far one one is enthusiastic about them, but if Libre Planet 
> (conditionally) approves them, I will do that. I agree the API may change.
>
>>
>> >> I'm not certain any more that we should be using subpages that rely on /
>> >> to create namespaces. From what I'm being told that's not really the
>> >> Mediawiki way of doing things.
>> >
>> > 'subpages that rely on / to create namespaces' <-- I don't understand.
>> > Namespaces are created statically by the webmaster and are not influenced
>> > by page creation.
>> >
>> > To back up a bit: mediawiki _developers_ created a wiki that can
>> > construct pages as a tree data structure. This is a typical and efficient
>> > software data structure for both storing and accessing _related_
>> > information. However, the developers did not provide all the functions
>> > necessary to manipulate the structure efficiently. Consequently,
>> > mediawiki users seldom create related pages in a tree structure because
>> > it is hard to maintain, so there is an existing culture to avoid
>> > subpages.
>> >
>> > I have (hopefully) added the missing functions, so using subpages is as
>> > easy to use as single pages. Now people can add related pages as a tree
>> > structure, so the content can be navigated in a relational way. In this
>> > sense, it is _more_ consistent with the _developers_ idea of the wiki,
>> > than the culture. The page content and page relationship are merged and
>> > the wiki has a consistent look-and-feel to it.
>>
>> Okay, I'm sorry to continue being dense about this, but I need a *short*
>> example that demonstrates what these functions do. It would help a lot
>> to see a concrete example of something that is hard to do with default
>> Mediawiki that these functions solve. I am getting closer to
>> understanding I think, but not quite there :).
>
> whew, examples are hard to explain, but I'll try. A visual demo is far easier.
>
> Take the SessionSchedule page as an example. The schedule provides several 
> events which are subpages to SessionSchedule, such as SessionSchedule/LFP, 
> SessionSchedule/SchoolsAndLibraries, and many others.
>
> Now we see mysql can't cope with long names so we want to shorten 
> SessionSchedule to LP09Events. The problem is that the current mediawiki will 
> allow us to move SessionSchedule to LP09Events, but all the subpages will 
> still be 'subpages' of SessionSchedule. The only solution is to move each 
> page individually without typing errors.
>
> What we really want to do is move SessionSchedule _and all its subpages_ to 
> LP09Events. My functions will allow you to move SessionSechdule to LP09Events 
> and SessionSchedule/LFP and SessionSchedule/SchoolsAndLibraries and all pages 
> starting with SessionSchedule. So in one move we have renamed many pages and 
> can now access LP09Events/LFP, LP09Events/SchoolsAndLibraries.
>
> If at some later point we decide to merge LP09Events into LibrePlanet, we can 
> simply multi-move LP09Events to LibrePlanet/LP09Events - and all LP09Events 
> subpages will be moved too. Now we can access 
> LibrePlanet/LP09Events/SchoolsAndLibraries.
>
> Again, if we decide we no longer want LP09Events pages, we can multi-delete 
> LibrePlanet/LP09Events - and all its subpages. So not only will 
> LibrePlanet/LP09Events be deleted but so will LibrePlanet/LP09Events/LFP and 
> all the others, such as LibrePlanet/LP09/LFP/Comments/..., 
> LibrePlanet/LP09Events/SchoolsAndLibraries/...
>
> Since we do not know exactly what subpages have been created for 
> SessionSchedule, it is currently hard to know whether we've moved them all. 
> My functions simply get the wiki to find and move/delete matching pages.
>
> More examples, if we decide that we want to move LP09Events/LFP from the 
> schedule into current_events and call it LibreFilePermissions instead, we can 
> move LP09Events/LFP to current_events/LIbreFilePermissions  - and all LFP's 
> subpages will move too. Now we can find 
> current_events/LibreFilePermissions/Comments.
>
> We may decide a group's page name is inappropriate, such as DownWithLP, so we 
> can multi-move DownWithLP to LPForever, and _all_ the subpages will be 
> renamed, too. With one function we have renamed many pages.
>
> The point is that standard mediawiki only handles single pages, but provides 
> subpages which should stay connected to the parent page. My functions 
> recognize the relationship between pages and handles them along with the 
> parent page. We assume that if you move SeesionSchedule, you also want its 
> subpages to be moved too and remain subpages.

Okay, the example did help and I understand now what the extension does.

But, I think we want to be moving away from using subpages separated by
slashes. I know we started out going in that direction.

I think we can accomplish what we need to accomplish using categories,
subcategories, and namespaces (in the standard mediawiki way of
Help:Foo). So we wouldn't need to install custom software and wouldn't
be swimming upstream.

What do you think?

-- 
John Sullivan
Manager of Operations
GPG Key: AE8600B6