[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Number of articles
OK - here's the real deal. Most of the stuff I said below is right, except -
I'm going to do away with type=7 and l=??? No more links.
That will simplify everything... it isn't needed. I figured something else better
out.
Actually, type=8 will become type=7.
So.
You'll have links that have type=6&p=5 and ones that look like type=7&p=5.
So within the following URLs:
/render.php3?o=1.3.5.90&type=6&p=8
/render.php3?o=1.2.8.95&type=6&p=8
/render.php3?o=1.3.5.91&type=7&p=8
the first two point to the same thing, and one is filtered out. The third is
different and is kept. You can have multiple type 6's and type 7's with the same
p.
type=???&p=??? is your unique identifier.
Make sense? I'm sure you guys can make that work right?
Jason
On Fri, Jul 16, 1999 at 02:38:54PM -0400, Jason Pincin wrote:
> 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.