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

Re: linux news project impressions

In message <199808221820.OAA13864@cran.mit.edu>, corbet@eklektix.com writes:
>The scope of the project seems to have expanded.  The initial goal, as I
>understood it, was to have a mechanism by which somebody could submit a
>news item of interest to just one place and have it propagate to all of the
>relevant outlets.  This still strikes me as a good idea.  But what I see in
>the proposals is a whole complicated system which directly addresses the
>news presentation side as well.  It's as if the existing Linux news
>resources are (1) to be replaced by the new "Linux News Service," or (2)
>reduced to differentiating themselves by their choice of GIF files that
>they place around the news items on their pages.  Now, if you can create
>something that will replace the Linux Weekly News, we'll gladly drop it and
>gain back a lot of time for paying work.  But that seems ambitious.

My original goal was to "come up with something that would make news sites
more coordinated". We've been brainstorming over some good ways to do that;
some of them are pretty simple, and some of them are pretty complex.

>It seems overly complicated and overengineered.  Do we really need NNTP
>servers?  Do we really need XML?  If we use XML, who will put all of the
>news items into that format?  The submitters?  If we want people to
>actually use this service to submit news items, it has to be trivially easy
>for them to do.  We can not expect them all to learn XML.

We do not really need NNTP servers. I agree that that is an overly
complicated solution, and I've put that part of the project on hold until
I/we come up with a better way to handle the news transport element. As for
XML, no, we don't *really* need it, but we need something like it. We need
some sort of formatting language to make news portable and easy to read from
a variety of different ways.

Part of the goal of lu-news is to define a standardized news description
format, and encourage people to use it. One of the problems we're trying to
solve is having 'free verse' news articles like the ones on cola: it's
difficult to skim those, and it's certainly even more difficult to sort and
categorize them in an efficient and reliable way. If we have more fields for
people to fill out, then we can encourage people to provide more data about
their news.

Using a web gateway for the news means that there's a simple web form to
fill out, with each field already listed. The web form will automatically
convert the submission to xml in the background, and then people can convert
that xml into whatever format of news they want to show the public, sorted
or categorized by any of the fields.

>Here is what I would propose to solve the initial problem:
>- Create a mailing list to which people can submit news items.  I would
>  happily host such a list, with as many of you as want as moderators.  Or
>  it could go elsewhere.  We could consider multiple lists for a
>  first-level categorization if we want.  The list(s) would be intended for
>  Linux news providers, but I see no reason to limit subscriptions in any
>  way.
>- Maybe make a nice web interface somewhere for submitters who prefer that
>  approach.  
>- Publicise the list/web site.

I don't think this is any better than cola. I think it's mighty similar,
in fact. My current plan was to
- create a web interface for submissions, including designing what fields
  and categories we need
- write some basic xml->news converters. Since xml is formed like html, I
  can use sdoc, which is a generic extensive html parser with some really
  handy features.
- advertise it.

I'll grant you that this is more work than what you propose. It's a very
interesting point, though, that *users* aren't going to be able to tell
the difference if we're using xml or whatever as a backend, so it might be
a good plan to get this set up and advertised now, and then we can fill
in some new fields and a backend later on.

>The amount of work is trivial, and, assuming that the news sites hook in,
>the initial problem is solved.  We could have it working in a day.  I guess
>I really don't see what we gain by doing something more complicated.
>So, what have I missed here?
>Jonathan Corbet, Eklektix, Inc.

Thanks for your comment. I'm sorry I'm not able to put as much time into
this as I should. As usual, I have several other major problems going on. :(

Some thoughts I wrote down after my discussions with scoop:

Benefits of having the same news duplicated on multiple sites:
* Greater chance that that news will be available to the reader all the time
  (not all of those sites will be down or full)
* Fewer sites to remember to check, since many sites will have at least the
  important news

Benefits of having a standard description format:
* Sites can use a standard well-designed form for submission, which will be
  familiar to submitters
* Archiving will be made simpler and more powerful: you can search or sort by
  any of the fields or headers, maybe even in the same way at each site
* Sharing news in realtime from one site to another will become much more
  reasonable, since either the sites will be using the same format, or else
  the conversion process will be more straightforward.

Categories: (this is in random note form, I haven't started a real list yet)

o Software announcements like those on freshmeat
o Press announcements from companies and other independent news agencies
o Commercial software listings like those on Linux Mall
o event announcements
o web site announcements

There are several types of things that can be categorized:



new announcements
updates/new versions/modifications/amendments

has a huge list of categories specific to software and such. It doesn't
quite suit us, but it has some nice ideas.

There's nothing saying we have to have one big overarching set of
categories that everything must fall into. We can simply have a series
of 4 clickboxes (pick one of [news, editorial, announcements, ...], pick
one of [new/update], pick one of [software, hardware, companies, ...], ...)

and from there, we can xml the sucker, mail it to participating sites,
and then they can xml->whatever it according to how they want to sort
and present it.

(This means we can get a rough set of categories/sorting_fields functional
in the near future, implement it, and then expand and solidify.)
(This also doesn't address the goal of copying news from one site to
another. This will happen once we have the categories and fields more
firmly solidified.)