Issue #74 resolved

mad url redesign / item lookup idea

Thomas Waldmann
repo owner created an issue

for the wiki, the url needs to identify a resource the code operates on then.

usually we used to give a name to identify a wiki item (and default to latest revision). or, a name plus a revision, to identify a specific revision.

the indexing layer (using whoosh) then uses this data to look up the revid we need to give to the backend.

we could generalize this idea so that the url just gives SOMETHING we can give to whoosh to identify the object(s) we want.

could be: {{{ itemid:... revid:... name_exact:... (default) }}}

(every unique key would work to indentify a single object)

if the lookup gives more than one result, we maybe could show a selection, so the user can choose what he wanted, e.g.: {{{ tags:... userid:... (revs edited by this userid) language:... (all items in that language) content:... (show all items with that content itemlinks:... itemtransclusions:... }}}

Comments (12)

  1. Thomas Waldmann reporter

    we would also need to give an option to select the index used for the lookup.

    default: latest-revs index, but optionally also all-revs index (or even another index, use an index name, not a flag).

  2. Thomas Waldmann reporter

    another vague and even more mad idea is to not only lookup the item/revision with whoosh, but also the action/view that should be used. needs more thought.

  3. Thomas Waldmann reporter
    server/++itemid:xxxxxxxxxxxxxxxxxxxxxxxxxx # or any other symbol instead of ++

    note: disallow + / ++ in item names


    or rather just use this?:

    server/?itemid=xxxxxxxxxxxxx&.... # somehow QUERYstring seems like a good match :D
  4. Thomas Waldmann reporter

    while discussing the ticket system gsoc 2012 project, we just found another application of using itemids to identify itemds (tickets): often such items are numbered 1,2,3,... but such numbers are evil as they are not globally unique, thus stuff gets mixed up easily when done in a distributed manner (see that bitbucket extensions closing the wrong issues).

    so we'll just use the itemid (long hex uuid) to identify tickets.

    to be able to do lookups with shorter ids (if copy&paste doesn't work), we can do a prefix search. if search results in multiple hits, show them to select one of them.

  5. Thomas Waldmann reporter

    Another idea for implementation: we already have namespaces (to separate items, to route them to different backends). Like wikiname:ns1:ns2:itemname.

    We could introduce another layer there: one can see the different ways to "address" an item also as using different (virtual) namespaces with different kinds of names (ids, ...) in them:

    • name:xxxx - address via the name ns (default, just xxxx does the same)
    • itemid:xxxxxxxxxxxxxxxxxxxxxx - address via itemid ns (good for nameless items)
    • revid:xxxxxxxxxxxxxxxxxxxxxx - address via revid ns (to get specific revision)

    So the full addressing is like: wikiname:ns1:ns2:virtns:name

  6. xiaq

    virtns looks like a neat idea, but I wish that I don't have to always write wikiname:ns1:ns2:...:virtns:name when I just want to qualify one of wikiname, namespace, or virtns. Perhaps we can make it possible to omit some component to mean "use the default", like wikiname:ns1:ns2::name omits virtns which defaults to name. However, since : is also used as the delimiter between namespace levels, this can cause some headaches. (Even if the developers can figure it out, new users will suffer from the headaches too. :)

    I suggest to use different characters for 1) wikiname terminator 2) namespace delimiter and terminator and 3) virtns terminator.

    Also, since there doesn't seem to be many virtnses (only 3) within sight and it seems there won't be more of them in future, perhaps we can drop the idea of virtns and use special prefixes (which should be forbidden in item names) to mean "look up by itemid" and "look up by revid".

  7. Log in to comment