That all makes sense, but we should try to not add yet another
directory-like structure. First of all, it *is* directory-like, so we
should use path separators. (We're talking about Horde 4 here, right?)

I can see some of this being additive to current code, but most likely, yes.

We might want to adopt the rewrite urls for browse() too, so have the
same directory structure in all browsing methods (internal and web
browser).

That all makes sense, but we should try to not add yet another
directory-like structure. First of all, it *is* directory-like, so we
should use path separators. (We're talking about Horde 4 here, right?)

But we already have two, sometimes different, ways to access object by
url. There is the browser view with rewrite rules and slugs. And the
"browse" interface that is used by webdav and obrowser. The latter
should be used for internal referencing, because that's actually what
obrowser is for, and the browse() methods already return the object if
you pass it a node path.

We might want to adopt the rewrite urls for browse() too, so have the
same directory structure in all browsing methods (internal and web
browser).

(well, it will get you the 'provides' name for those apps). I think we
need to do some work for this feature to be really useful. The show
api method isn't really appropriate for this because it requires named
parameters, which would be awkward:

task:id=2

task:id:2

etc.

I think what we really want is something like path-based browsing,
with slugs, and to have slugs auto-generated where reasonable for the
groupware apps. Calendars tend to have the same thing a lot, so that's
tricky, but we could replace spaces with - in task and note names to
get a reasonable guess. Combined with named shares... but you can see
this is a bunch of changes.

For bugs it's simple:

ticket:id

now that we have queue slugs:

ticket:queue_name could probably be recognized also, though we'd be
unable to distinguish ticket ids from queues with all-numeric slugs
(my not-so-unreasonable example for this was a photo gallery named
"007").

OK, so this is my very rough starting point. It uses detail in the
registry file, which identifies what each "module" provides. I hope
I've got it right, as I'm struggling a little working out where to
insert this call in the rendering sections.

I guess a further enhancement would be to loop through the registry,
looking for active modules which have a "show" function in the API.
Can someone take a look and let me know if this is possible?

Well, there's not much to offer really, but I'm writing some stuff
into the Horde_Text called wikiLikeLinks which will be called by the
various text-to-html functions, and uses detail in the registry to
provide the link codes and URL destinations.

The main delay is that some personal stuff has come up since starting
writing it, and work stuff is intruding a little as well, sorry to say.

As soon as I can get something together I will. Is there a status of
Paused_Pending_Life_Getting_A_Little_More_Simple? :)

This is something I'd like to see. Very similar to the way that Trac
works (which I hope to be replacing for Chora + Whups + Wicked), a
wiki entry, referring to ticket:blah will link to the whups ticket,
where you can write "This is as per wiki:WikiPage", that refers to the
wicked page that specifies a source:/path/to/file for chora links.

The base horde system ideally would be able to then extend this,
allowing the author of a block to refer to
[note:Some_People_Who_Know_About_Stuff], task:12345678
contact:fred@bloggs.com or date:2008-05-27 or file:/something/something.txt for mnemo, nag, turba, kronolith and
gollem accordingly.

There's already a degree of this in Wicked for integration with Whups,
but it's not very easy to configure (needing knowledge of regex), and
it doesn't work both ways.

I'll try and see if I can start putting some stuff together to get
this working, as I'd like to move away from Trac as soon as possible :)