Re: [Pan-devel] Re: ancient DB schema

[K. Haley]

Duncan wrote:

> K. Haley posted <address@hidden>, excerpted below,  on Sat,
> 05 Jun 2004 00:30:52 -0600:
>
>  
>
> > Unresolved: should we handle multiple hostname+port pairs? (just remember
> > to seperate servers that handle different groups.)
> >    
>
> That's an interesting idea..  My ISP (Cox Cable) has three servers
> number-synced between them, and carrying the same groups, altho there are
> slight retention differences and there's one per region, so some
> distance variation.  Multiple host/port pairs per server would allow me to
> put them all on the same server.
>
> OTOH, I'm not sure it's worth the trouble, particularly once we get
> automated multi-server handling, as it'd work just as well to make them
> three separate server entries as I do now (and that'd solve any minor
> retention difference problems as well).
>
>  
Actually IIRC that idea came from Charles, the comment in () was mine.  
You're right in that multiple entries would be better for handling any 
differences between the servers.  That was actually the way I expected 
it to work.

> Perhaps a better use of such a feature would be "virtual" servers, which
> would display multiple servers as one but continue to track them
> separately. 
>
> In fact, as I think about it, perhaps the most efficient way to do it
> would be to support virtual servers almost from the start, by splitting
> the structure such that the group contents of physical servers are never
> really displayed at all (except perhaps in a diagnostic screen), only
> back-end tracked, with the normal front-end display being entirely
> separated as a a virtual server, and the plumbing between the two, save
> for configuration, handled entirely transparently.  
>
> This would allow flexibility in a number of ways.
>
> In the simple case, single physical server, single view of it (virtual
> server), it would function much as it does now.
>
> I believe it's fairly common among Usenet junkies, even when there's only
> one physical server available, to split it into multiple logical servers,
> providing at least one level of hierarchal nesting.  Thus, one may have a
> "pix" server, a "movez" server, a "isp" server, a "linux" server, an "ms"
> server, etc, all pointing at the same physical server.
>
>  
....

> Likewise, the virtual servers being only views on physical servers, could
> collate the view of the same group on multiple physical servers,
> prioritizing physical server fetch, but with each physical server back-end
> still managing it's own connection limits.
>
> In this scenario, the physical server backends could be "dumb", not
> knowing or caring how many virtual servers were hooked to it.  It would
> have to track max connections and etc, but wouldn't even have to track
> rank, as the virtual servers would manage that.  This would keep the
> physical server records almost of fixed size (assuming one set a
> reasonable max size for the various strings, they COULD be fixed length
> records).
>
> Each virtual server, then, would have all the complicated variable length
> stuff, as each could have multiple physical server pointers, each of which
> would have to contain not only the physical server pointer, but a
> hash/bitfield of the displayed subscribed groups actually carried by that
> server, AND a priority level.
>
>  
...

> Of course, something like that will certainly mean a rather more intense
> rewrite of PAN as we know it, than would a more conservative approach, but
> it's quite likely, IMO, that PAN will never really be able to handle
> multi-servers /well/, until such a modularized approach is taken.
>  
What you've described should be easy to implement.  All that's really 
required are new tables listing the subscribed groups for each v-server, 
the rest of the back-end can remain the same with all group info being 
tracked from the global group list.  The only question is the interface.

1. We list the v-servers in the server menu with a 'default' server 
always present.  This default server will get its subsribed list from 
the main groups table.  Additional v-servers would each have their own 
table listing only the subscribed groups.  When subscribing to a group 
in a v-server the group will be added to the v-servers table.  These 
additional table merely point to the group entry in the main table to 
keep the info consistent across v-servers.

2. We list the v-servers in the groups combo-box along with FOLDERS, 
ALL, SUBSCRIBED.  The only problem is adding a group to a particular 
v-server.  Otherwise it's the same as the first suggestion.  I suppose 
we could make subscribe context sensitive.  If there is only one 
v-server it works as today,  If there are more then it brings up a list 
to choose which server to add the subscription to.

In both cases download and reading are handled the same as they are 
now.  We add tasks to the task list and let the connection limits and 
task order handle the rest.  We would also need the following two tables:

TABLE vservers
  ! name    (UNIQUE string)  name of v-server and its table
  * id         (INTEGER PRIMARY KEY)

TABLE ????
  ! group   (UNIQUE INTEGER)  group::id
  * id        (INTEGER PRIMARY KEY)

At least the back-end should be the same for both interfaces.

signature.asc
Description: OpenPGP digital signature