Re: Aaron is going to kill me.

[Aaron Turner <aturner@linuxkb.org>]

On Thu, 12 Aug 1999, Jason Pincin wrote:

> Maybe we need to hash this out on IRC but here's where your reasoning in
> the last email was wrong:
> 
> The last number in the o= string does not translate to the article ID or
> anything like that.  Every container, application, article, user, etc.
> has it's own UNIQUE entry in KBObjects thus giving it a globally unique ID
> among all objects.  So, if 1.4.8.23 is an article (type 6) that maybe
> points to Article ID 7 or sumthin... thats fine.  You really don't hafta
> care what the article ID is.  Because that 23 on the end there will ALWAYS
> be the ObjectID used to access that article, and nothing else will have an
> objectID of 23.  Understand what I'm saying?

Yeah.  So the last number of o for type 6 or 7 is basically the Article
ID.  Yes I realize that it's NOT the article ID, but really it could be
for all I care.  That's fine.
 
> So... All p= does right now is give the unique ID of the record in the
> extra info table (such as articles) via the URL.  I don't need it
> anymore... but if you wanna keep using it I'll leave it in there.

Lost me there.  "Id of the record in the extra info table"???  Speak
english not SQLish. :)

> Yes, you can still distinguish between docs and articles, etc simply by
> type=.

Cool.

> Does Dean still need some kind of ID or anything?  The last number on the
> o= string will be his unique number... the only thin he needs to filter on
> is type=.  He only wants type=6 and type=7.  Beyond that he just wants to
> remove entries that duplicate the last number in o=.  Thoughts?

Well Dean doesn't need to worry about the type at all since they will have
global unique values.  I'm guessing that it would be less CPU intensive if
you could provide a dedicated ID field for articles and mirrored content
for him to detect uniqueness.

> Also - in reference to alist.php3, the URL for that may change.  Remember
> how we talked about the s=<something> to denote the two different search
> types?  Well... I was thinking :).  Howabout making that action=.  Then I
> could list in render.php3 a list of possible actions for each object type.
> For example, an object type of 3 (KB Container) would have the following
> actions:  SimpleSearch, AdvancedSearch, ArticleList, AdminView, etc.

I just came up with a killer idea.

Ok, Jason.  I need a small favor.  Please add:

<META NAME="htdig-noindex">

To all your templates that do not return articles (type 6 or 7).  This
will prevent Ht://Dig from adding these pages to the database, but still
allow htdig to follow the links on the pages to find the articles.  This
will allow me to NOT use restrict on each htsearch query and save some CPU
on each search.
 
Anyways, do what you will with the alist.php3 thingy.  It doesn't effect
me any.

Assuming you can do me this little favor, all I care about is the
structure of the URL's for the articles (type 6 and 7).  That's it.  You
can change everything else tomorrow and then again next week for all I
will care, because it won't effect me at all.

> So... the alist.php3?... URL would become
> /kb/doc/render.php3?o=1.4.8&p=4&type=3&action=ArticleList
> 
> (assuming we keep p=)
> 
> Thoughts on that?
> 
> You said it'd be good to know in your Perl scripts which search form was
> being used, so you could just check action= for either SimpleSearch or
> AdvancedSearch.  Gimme your feedback on that idea.

Ok, so howabout we use the following URL for type=6/7:

/kb/doc/render.php3?action=[ss,as]&o=0.1.a.b.c.Z&id=Z&type=[6,7]

These URL's will be the only ones without the META tag I mention above.

If you want "AdvancedSearch" vs "as" that's fine too.