Re: Number of articles

[Aaron Turner <aturner@linuxkb.org>]

/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.