[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Number of articles
And, what we discussed the other night is still valid. Remember we discussed
versioning Aaron? So if I select I only want articles that effect apache 1.3.6 and
that results in a URL like this:
/render.php3?o=1.3.5.90&type=6&p=8&d0=102
You'll be able to filter further on the d0= so long as that info is passed in via
the search form right?
I think we determined that would be fine, but remember to include the possibility
of a d0, d1, d2, etc flar in your variable placment when you tell me that.
Jason
On Fri, Jul 16, 1999 at 02:53:03PM -0400, Jason Pincin wrote:
> 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.