[PP-main] My thoughts

[Rusty Foster]

Joakim Ziegler wrote:
> 
> On Wed, Mar 08, 2000 at 10:50:23PM -0800, Raph Levien wrote:
> 
> > HTTP vs roll-your-own
> > ---------------------
> 
> > I come down firmly on the side of HTTP here. I can easily believe that
> > Flux has a number of real advantages. But HTTP is so universally
> > supported by the servers that we're hoping to bring into the Peer
> > Press network that we will certainly be implementing HTTP
> > anyway. Having two protocols strikes me as needless complexity, when
> > we know that HTTP will get the job done.
> 
> I support using HTTP, definitely. I'm not sure how having more than one
> protocol available for use will increase complexity, given that we want to
> decouple the storage system from the protocol, which I assume.

You said it. What we're developing is:

1) A format for data exchange (XML)
2) One or more compatible implementations.

As long as the data *may* be exchanged over HTTP, then we're fine. 

> I suppose the way it'll work with HTTP is to send HTTP POST requests to
> specify the data you want, or even use uploading to send larger chunks.
> This'll probably work. In this case, I think the correct way to implement
> would be as an Apache module, in C. The storage backend could be flat files,
> or we could possibly use Flux for it, it has some very nice, and very fast,
> embedded database functionality. But I'm not going to push Flux for that
> specific purpose, I'm sure I've done enough marketing for a while already.

Or it could be written as a perl module for Apache (I'll volunterr to
write that one!), or as an INTERCAL module for FooServer version 12.
Basically, it doesn't really matter how you exchange or store data.
Ideally, clients and servers could talk to each other, no matter what
they were running. More realistically, I'd say that any given network
protocol should have a standard implementation, that clients and servers
must conform to. So, there could be any number of http-based server
implementations, but they must all respond in the same way to the same
request syntax. Same goes for flux, NNTP, what have you. Sound
reasonable?


> 
> > XML wierdness
> > -------------
> 
> [Snippage]
> 
> > There is one area of "advanced" XML usage I recommend we pay attention
> > to, though, which is internationalization. This means UTF-8 encoding
> > for Unicode, and language tagging (at least for non-English
> > languages). I'm a fine one to speak, as Advogato currently bails on
> > both of these issues. But I do feel that paying attention to them now
> > will save much trouble later.
> 
> I totally agree. Exchanging data in UTF-8 from the very start will probably
> also ensure that systems don't fall over the day the actually need it.

I third this recommendation. I don't know enough about XML to be
authoritaive, but internationalization is *really* important.

> 
> > Centralized vs distributed
> > --------------------------
> 

[snip centralized vs. distributed comment]

> This works for me. There's one thing I'd like to do, though, which will take
> us beyond the level of simple RDF/RSS syndication, which is have the central
> server download all the stuff from the different feeds, so that we could in
> theory do push stuff later if we wanted, and also do centralized searching of
> the entire feed, etc., etc. Where the information is actually downloaded from
> when it's time to fetch the article/photo/whatever isn't that interesting, in
> my opinion. The main point would be some central starting point to get a hold
> of all of it.

What I envision is something like a "distributed, centralized" system.
Bear with me here :-) Imagine we run PeerPress, which is the first to
actually implement this whole scheme. Someone else could come along and
startup BigFish News, which uses their own server network, and finds
their own feed clients. What would be ideal is if our central servers
and their talked to each other, so content flowed up to us from our
clients, and up to them from theirs, and then across from central point
to central point. Now add n^2 other networks communicating this way, and
you (I think) have all the advantages of both systems.

> 
> > Syndication of identity
> > -----------------------
> 
> This scheme sounds sane.

Yes.

> 
> > Crossposting
> > ------------
> 
> This too. As I've mentioned before, I think, I'm not that interested in the
> discussion syndication, I believe a system for it should be in place, and
> this sounds workable for all parties.

Hm. This one needs some more thought, I think. I don't have an answer
yet, but I'll ponder some more.

Trust stuff... I don't know about that either. My only real feeling on
that is that there should be soem fairly generic format for publishing
"trust" and beyond that, the implementation should be user-defined.

--R

-- 
=======================================================================
|      Rusty Foster       | "You can never entirely stop being what   |
|   rusty at kuro5hin.org    | you once were. That's why it's important  |
|    rusty at intes.net      | to be the right person today, and not put |
| http://www.kuro5hin.org | it off till tomorrow."        -Larry Wall |
=======================================================================