[OGo-Users] links to documents

[Adam Tauno Williams]

> > WebUI seems to make a conspicuous effort to
> > hide object ids (one never sees a JobId# for example,  a darn useful
> > kind of thing)
> I'm not against numbering/coding objects, but the documentId like the  
> jobId is an articial, internal primary key and should never be exposed  
> as UI. In fact it can become quite huge (273722738782), hence its not  
> useful for transmittion either.
> What you might want is another unique key field. Like the 'number'  
> field in projects and contacts. Usually people invent their own  
> numbering systems for cases, projects, contacts .. and maybe even jobs.

True,  that would be ideal.  But unless there was some kind of plug-in
mechanism to facilitate generate/assignment of those ids it isn't very
pragmatic - the number has to be created outside and copied in.  For
contacts, etc... created by GroupDAV for example have no "number"
unless/until one is "patched in".  Then everything that consumes the
data needs a special case to deal with items that have [yet] no number -
that becomes a real pain.

Another issue is that some object types, jobs for instance, have no
"number" field so I'd have to modify the schema/model or use an object
property which seems awkward for a search-frequently kind of value.

As for the potentially "huge" size of the id,  I don't see a problem.
"273722738782" is still significantly shorter than a VIN#, an ISBN#, or
a DMV#;  numbers commonly in use.  Large databases equal large ids
whether they are strings or numbers.  At least my user's typically
cut-n-IM large id number of various kinds to each other.

I understand the aversion to external use of the the primary key.  But
in my opinion, OGo's nearly universal use of the sequence id is a great
boon for developing various clients and consumers.  It is simple and
fast.  objectId + objectVersion makes both catch-up and conflict
detection easy if the client has a cache.  That was the reason behind
Bug#1915
<http://bugzilla.opengroupware.org/bugzilla/show_bug.cgi?id=1915> as
otherwise calendar clients have to do allot more work to make sure they
don't loose data and update the correct data.   Of course this is a bit
different than *displaying* the id in the UI;  but see the last part of
this e-mail.

Having to refer to different kinds of objects by different means would
be dramatically more complicated -  that is one of the primary reasons I
made zOGI.  My MOGI (wrapper around the old XML-RPC API) had become a
snarled mass of hacks in order to hide inconsistent behavior from the
actual client - when the internal behavior of the server actually is
quite consistent;  thus the old XML-RPC served partly as a layer of
deliberate obfuscation.

> The current use case for finding tasks is project oriented, aka 'have  
> a look on your tasks in project code 182/293/11-12'.

True, and that works in most cases.  Maybe we are pushing past the
intended use of the application as we view those completed tasks as a
knowledge base,  and a project can contain allot of archived tasks.
Having a id# of a notation is much easier than "the notation made by XYZ
on 2006-10-02 of the task {description} describes what was done",
especially if that id can immediately bring up the content.  So if I'm
referring to something like that [in an application] it is hard to come
up with a more useful/meaningful label other than the id.   MOGI
originally tried some things like using the first line of an annotation
as a "title", or using a contrived human-readable id like
"task/{description}/annotation/7" but for a handful of reasons that was
a pain as well.