[PP-main] Technical/implementation matters

[Rusty Foster]

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


> >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?
> 
> Hi,
> 
> 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
of implementation.

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. :-)

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