bvs@light.uucp (Bakul Shah) (03/15/90)
Reading all these news reader reviews makes me think we need to
separate the issue of *presentation* of news from its *access*
(roughly speaking. I can't think of a better way of expressing
what i have in mind).
While all the readers reviewed here so far and even Notes and
readnews (remember?) let me access the news system (i.e. let me
read/discard articles, tell me if there is something not read by
me in a group, subscribe/unsubscribe groups etc.) they don't
present this information in the way _I_ like.
If the access layer is separated out, people can concentrate on
building better presentation software or even embedding news
access in other software. Similarly, people can experiment with
other ways of organizing the news database as long as they provide
the same access interface.
Here is the basic idea to get the ball rollling.
- *Model* the news system as a set of objects and relationships
between them. Define operations to add/delete/change these
objects and relationships. Then relaynews, expire, news-readers
all become specialized applications that will access the news
objects via a clean interface.
Group Operations:
create, delete
moderate, un-moderate // and other attribute changing ops
add-article, delete-article
add-sub-group, delete-sub-group
Article Operations:
create, delete
send-to-system, receive-from-system
attach-property, detach-property
User operations:
add-user, delete-user // these may be implicit
subscribe-to-group, unsubscribe-from-group
read-article, write-article
cancel-article, reply-to-article
filter-group // to filter out unwanted stuff
- Maintain important relationships such as articles-read-by-user,
articles-not-yet-sent-to-system, articles-ready-for-expiry,
group-expiration-schedule, groups-we-are-interested-in, groups-
our-neighbor-wants and so forth.
This is just to give a flavor of what can be done. A real design
would involve specifying lots of details.
I suspect most of the code to implement these objects can be
cribbed from existing tools. The important thing is to a) come up
with a model that accurately (and simply) reflects how a news
system is accessed in real life and b) replace built-in
dependencies on various specific files/directories with an object
interface. I might fer'nstance want to suck-up all the news in a
news-server with 4Gig virtual address space and simply dole out
articles as requested.
So. WhaddayaThink?
-- Bakul Shah
bvs@BitBlocks.COM
..!{ames,sun,ucbvax,uunet}!amdcad!light!bvsdce@smsc.sony.com (David Elliott) (03/16/90)
This is similar to something I discussed briefly with Harry er.. Henry
Spencer last year.
One thing I also considered was a generalized "preferences"
mechanism a la X resources. The user would have a database
of preferences that would be used as needed by the various
libraries and interface programs.
This would allow someone who uses many newsreaders to have one
single set of preferences. In my case, I use rn at home, but
I would prefer to use a more graphical interface (though I don't
like xrn at this time) at work.
Thus, it should be possible to give both general and specific
preferences. For example:
FollowThreads: true
rn.FollowThreads: subject
That is, for any newsreader but rn, the FollowThreads attribute
is "true", implying some general thread following mechanism. For
rn, the thread following should use the attribute "subject", which
would imply some special case of threads.
By providing this mechanism, programmers should be more sensitive
to user preferences (though this is just starting to gain widespread
acceptance in X, due to most people not taking the time to implement
it in many programs).
--
David Elliott
dce@smsc.sony.com | ...!{uunet,mips}!sonyusa!dce
(408)944-4073
"Yewhainuhnuthubudduhawndaw" -- Evis