[mb-style] RFC: Works lists (and other related changes then implied)

[Brian Schweitzer]

On Sun, Mar 30, 2008 at 8:23 PM, David K. Gasaway <dave at gasaway.org> wrote:
> On 25 Mar 2008 at 22:27, Brian Schweitzer wrote:
>
>  > You keep
>  > using a choice of wording that implies that these are somehow out in the
>  > grey lala land bordering on something we don't want. Sorry, but get
>  > real.
>
>  The problem here is that you've mistaken my intent behind the whole
>  apache+user script idea.  It was an off-the-cuff brainstorm to meet
>  your very strict user script requirements while accomodating the wiki
>  and without changes to MB.  It was a solution *for you*, and I have no
>  illusions of applying it to a general audience.  Neither have I ever
>  had the illusion that it solves the UI script problem better than
>  folksonomy tags; that is an idea I rejected for other reasons already
>  given.
>
>
>  > Umm how?  You're duplicating the existing layouts already tried.  So how
>  > do you then trim the size of the page?
>
>  By dividing into multiple pages?  I don't understand the confusion.
>
>
>  > Let's see, I asked for why taking things back into the wiki was a good
>  > solution to the problem of how to get things *out* of the wiki, your
>  > response was "it's the best solution".  It's a solution that makes zero
>  > sense - give me reasons, not bluster!  :D
>
>  I never said "it's the best solution".  I said it was the best solution
>  offered - in fact, it was the *only* solution presented to my
>  questions, so it was the best only by default.  As to getting things
>  out of the wiki ... I guess I'd say that the work lists alone are a
>  poor way to get things out of the wiki, so let's not be too hasty to
>  toss it aside.
>
>
>  > It's not something "out of
>  > the blue" that I introduced.
>
>  Sigh.  It is definitely something that was dropped into this thread in
>  reference to this RFC weeks after the RFC and wiki idea came to light.
>  The discussion in re wiki pages in this thread to that point had
>  nothing to with UI scripts.  If you read my old post carefully, that is
>  the context of the "out of the blue" remark, but I hope I've provided
>  some clarification.
>
>
>  > And I think you perhaps
>  > recognize this, as you saw fit to not mention that you've somehow made
>  > this turnaround, going from "You wholly misunderstand what the wiki
>  > solution was about." to "Obviously I can't speak to the purpose behind
>  > the original design of the pages (and don't presume to..."
>
>  There's no turnaround necessary.  Once Frederic offered the idea of
>  using the wiki pages for certain particular purposes ("the wiki
>  solution"), under these assumptions it doesn't really matter what they
>  were designed for originally.  The only question was whether or not
>  they offered adequate solutions to these new problems.  Obviously,
>  there could be a issue if the change somehow made them unsuitable for
>  the original purpose, but no one has said as much.  If you don't like
>  the idea of repurposing them, say so, but I'll be left wanting for some
>  other solution.
>
>
>  >  - and yet,
>  > you continue to somehow suggest that your "solution" fixes things.  It's
>  > not a solution, David, if it fixes no existing problems: grouping,
>  > (realistic) scriptable access to the work list, and getting the load off
>  > the server.
>
>  Again, not *my* solution.  However, as far as I can tell, it does solve
>  the grouping, sorting, translating, indexing, multi-catalog, and
>  browsing functions well enough.  If you have an idea that addresses all
>  those things plus scriptable access and reduced server load, please
>  present it.
>
>
>  > Give reasons why you think going back to the wiki is so great
>  > an idea, considering what is lost by doing so and the load on the
>  > server, don't give bluster about "it's just a great idea, because it
>  > is!"
>
>  Going back to the wiki?  The way I see it, it never went away, because
>  the work lists do not provide certain other features already provided
>  by the CSGS pages.  The RFC, by the way, made no mention of eliminating
>  the wiki pages, so I had no clue this was part the plan early on.  Load
>  on the server was not a consideration because UI scripts and server
>  load were never mentioned in the RFC, and in fact not until weeks after
>  Frederic suggested the wiki.
>
>  Look, I'm not some stubborn "wiki solves all" zealot, and I don't see
>  how anything I've said could be construed as such.  Until a week ago,
>  the wiki was the only idea around and hadn't garnered a single
>  objection.  Thus, I was operating under the assumption it was a
>  solution that everyone liked.  If it really is a horrible idea, I can
>  accept that, especially since Frederic as all but disowned it. :)
>  However, that leaves my original questions unanswered.

Ok.  I'm not interested in debating timelines and such much.  Suffice
to say, the original RFC was made before the wiki server's troubles
became evident.  That original RFC has also been revised at least
twice since I originally proposed it.

Speaking with luks the other day in IRC, he basically said to tell him
what we want in work when they're implemented.  So let's drop this
whole RFC - it's already so convoluted and revised, let's break it
apart more simply.

Works that are broken up and such, so we "assemble" the title, are
will need a decent amount of discussion, and likely are too complex to
implement quickly.

But if we're going to write up what we want works lists to be (if not
as complex as above) for luks, let's maybe do it, and see if we can
solve the issues.

Issue 1: Wiki server is overloaded, increasing the numbers of works
lists in the wiki isn't going to help.

Issue 2: Grouping of works

Issue 3: Functional script-access for works.

Now, #s 2 and 3 really are mainly classical issues I think; most
non-classical is pretty much just alphabetical.  #1 would most simply
be solved by not tying anything to the wiki.

How about this:

The work list implementation should have:

* A single work title (with devolution of this for on-the-fly
construction and translation, some time in the (far) future a
possibility)

* Annotation abilities for both individual works and the overall work list

* AR abilities

* At least one catalogue field, preferably able to be titled, but if
field titling would cause works implementation to be delayed, that
part can be skipped.

* In any listing of works, they ought to be sorted by the catalog
field (if multiple fields are allowed, now or in the future, allow the
user to select which one is used for sorting/grouping), then by the
work title.

This would allow the cat # field(s) to be used for scripting.  Sorting
by cat # first would also allow grouping right there.  (Perhaps we
would also need some sort of group sequence field to sort on, instead
of work title, for opera/etc).  This seems like it would solve both
while also removing the need for any use of the wiki.

What do you think?

Brian