[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: K. Haley
Subject: Re: [Pan-devel] Re: ancient DB schema
Date: Sun, 06 Jun 2004 15:56:05 -0600
User-agent: Mozilla Thunderbird 0.6 (Windows/20040502)

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

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.

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]