[PP-main] Technical/implementation matters
rusty at kuro5hin.org
Fri Mar 3 19:32:36 CET 2000
Andrew Cooke wrote:
> At 08:38 AM 3/3/00 -0600, you wrote:
> >On Thu, Mar 02, 2000 at 06:43:57PM -0500, Rusty Foster wrote:
> >> I think http is the way to go for client<->server communication. It's
> >> cheap, easy, and everyone running a website already has it implemented.
> >HTTP could work, but it's really sub-optimal for this sort of thing. If I had
> >to choose an existing protocol, I'd rather consider NNTP. But I don't see
> >what's wrong with brewing our own. Of course, I have an ulterior motive:
> >We're doing some software here that's specifically made for transferring
> >pre-parsed tree data (for instance XML) and knows how to take XML as input,
> >and output it on the other end, diff trees, and things like this. It's also
> >handy because it's extremely easy to use (it's a C library, with very
> >high-level functions). It also has crypted streams built in, without the need
> >for SSL libraries or anything of the sort.
> >I'm not a big fan of the trend lately to use HTTP for just about everything.
> >It's not what HTTP was made for, and it's showing.
Yes, this is true, *but* HTTP was made for transferring text files in a
fairly lightweight way. And that, at heart, is really what we want to
> >My idea is to use the comm tool we're making at the bottom level, and then
> >supply some tools that use it, which let you do stuff like poll the server
> >for new messages, etc., command line. That's the most UNIXy and flexible way
> >of doing it, I think. Opinions?
> HTTP is everywhere. You don't need to worry about firewalls - if anything
> goes through, you can bet that they let http through. The main problems
> are a lack of state and that it's limited to a single request/response on a
> single open connection.
These were my reasons for recommending HTTP. Ease of use, ubiquity, ease
And lack of state isn't really all that much of a problem, IMO, for this
system. The communication can be as simple as:
* Client requests updates, providing UID and a passphrase (over SSL)
* Server authenticates, send file
You don't really need state to do this.
> One final comment - more personal opinion that the above - avoid new stuff
> as much as possible. You are doing a lot of work. Getting something
> working on existing protocols is probably quicker. Yes, it's interesting
> designing better more efficient protocols, but no-one wants to document
> them and no-one understands them. Efficiency is always over-rated.
> Optimize last.
I agree with this too. There's a lot of stuff to do, already. I don't
know if designing new network protocols is how we want to spend our
time. That said, if designing a new protocol would be a Big Win for
everyone, please explain why, and I'll definitely listen.
I think probably the best possible answer would be, design something
that *will work* over HTTP. It may not be optimal, but it should be
functional. Then, whoever wants to design a better or more efficient
protocol, can have at it. :-)
| 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 |
More information about the Peerpress-main