[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Number of articles
Hm. I did mention this to you via IRC. Maybe we disconnected somewhere :)
p=?? is the article identifier. But ONLY if type=6 or type=7. Actually, type=8 is
a link to external documentation and will need to be searched by htdig as well. On
type=6 and type=7, the p=??? will point to the same article if they are the same.
Example -
/render.php3?o=1.3.4.5.90&type=6&p=5
/render.php3?o=1.2.6.102&type=7&p=5&l=90
/render.php3?o=1.3.4.5.91&type=8&p=5
The first and 2nd will link to the same thing, article ID 5. The 3rd will link to
something totally different: External Link ID 5. Which could be the DNS HowTO, who
knows.
l=90 in the second example will only exist for type=7's. Type=7 signifys a "link"
to an article since articles will only have one parent now, but we still want them
to show up in different are's of the tree if desired. So type=6 is an actuall
article. That's why the p=??? on them go to the same place. The l=90 tells it
which object it's linking back to. This is a slight variation from my original
design because I knew it would have to be that way for htdig.
type=8 signifys a link to external documentation. It will link to the URL provided
in the ExternalLinks table with a unique ID of 5.
So, the answer to your question really... is that for type=7 or type=6, p=??? is
the unique ID across both.... grr... let me put it like this (im having trouble
portraying my thoughts):
If you get multiple type 6's and 7's with the same p, filter all but the type 6
link out. You'll never get more than one type 6 with any given p. If you get
multiple 7's and no 6's, pick a 7 at random, they're all the same.
For type=8's, filter them based on p=??? but seperate from the type 6's & 7's.
This a big fuckin mess isn't it? You tell me how I can improve it. I can be
completely flexible here... I don't have to change the DB at all to change the way
this stuff works. So feed me ideas. What messes everything up is the concept of
linking to an article... let me think for a few minuts... I'll send another mail
shortly. Maybe I can do away with that easily.
And yes, o=??? is taking the place of c=???
Does render.php3 need to be under articles for htdig? Because logicly it should go
under root, but if it's a problem for htdig, I'll change. I'll explain why I think
that logic applys if you want, or if it's even an option.
Jason
On Fri, Jul 16, 1999 at 10:53:50AM -0700, Aaron Turner wrote:
>
> /me hits Jason over the head with a bat for not mentioning this little bit
> of IMPORTANT information sooner. :-)
>
> Yes, this changes things. Search.pm is very particular about the URL
> since it has to parse it for important bits of information to generate the
> page.
>
> Ok, so what portion is the UNIQUE article identifier? is p=??? unique or
> is type=??&p=?? the unique part?
>
> What is l=??
>
> is o (object?) the new name for c (cateogory?) ?
>
> Once I have this, I will tell you what order to place the CGI vars in the
> URL's. The order is important to do the drill-down in htdig.
>
> what does type=6 mean? type=7 ? Is one an article in the DB and the
> other part of the mirrored content? ie a pointer to an external URL or
> something? We need to have a way to link to external content.
>
> Also, render.php3 should go under /articles/ and not live off the root
> directory.
>
> Let me know what's up.
>
> -Aaron
>
> On Fri, 16 Jul 1999, Jason Pincin wrote:
>
> > How are you guys intending on sorting based on article ID? I'm no
> > longer going to be generating URL's such as this:
> > http://www.linuxkb.org/articles/article.php3?id=1&c=1.3.5.7
> >
> > That is no longer valid.
> >
> > The new href's will look like this:
> >
> > /render.php3?o=1.3.5.7.50&type=6&p=1
> >
> > or
> >
> > /render.php3?o=1.2.8.9.81&type=7&p=1&l=50
> >
> > All links with a type=6 or type=7 are links to articles. In both cases, p=1
> > references the articleID.
> >
> > Let me know if this causes any problems or if this in any way changes
> > things for you. Thanks,
> >
> > Jason
> >
> >
> >
> > On Fri, Jul 16, 1999 at 11:08:02AM -0600, Dean Giberson wrote:
> > > I believe the Quick sort is n (Log n). The bit field would give n. Also with 1000
> > > articles the memory for each hit is 1000 * 4 = 4000 bytes (4 is the size of a
> > > pointer). For a bit field it's 1000 / 8 = 125 bytes. That's 32 times difference, I
> > > forgot about the size of a pointer when I said 8 times.
> > >
> > > I'm not saying I have to do it this way. It just seems to be more to your benefit.
> > > One problem is that I could not get the smallest article number with a bit field. So
> > > if that is nessecary then I will be glad to do the Quick sort.
> > >
> > > Aaron Turner wrote:
> > >
> > > > On Fri, 16 Jul 1999, Dean Giberson wrote:
> > > >
> > > > > Do the articles have to be sorted? If they don't then the overhead involed in
> > > > > setting up a quick sort can be by-passed and I could use a bit field.
> > > >
> > > > I was just thinking that a quicksort alogrithm would be faster for a
> > > > large number of results since it reduces the number of comparisions.
> > > >
> > > > > The Add/Remove functions already exist. And the search/scan fuctions
> > > > > would let me go through the list in a liner fashion.
> > > >
> > > > If that's faster, cool.
> > > >
> > > > > The bit field cuts the memory by 8, since I can fit 8 checkes into one
> > > > > byte. And the code size is reduced since I'm using existing code.
> > > > > Win-win.
> > > >
> > > > I would be more concered optomizing for speed than memory usage. We've
> > > > got 1GB of RAM.
> > > >
> > > > -Aaron
> > > >
> >
>
> --
> Aaron Turner, Core Developer http://vodka.linuxkb.org/~aturner/
> Linux Knowledge Base Organization http://linuxkb.org/
> Because world domination requires quality open documentation.