[DGD] The battle of the protocols (was: A small toy)

[Raymond Jennings]

On Fri, Feb 10, 2017 at 4:19 PM, <bart at wotf.org> wrote:

> On Fri, 10 Feb 2017 15:40:09 -0800, Raymond Jennings wrote
>
> > I beg your pardon, but TCP is a very standard protocol...just at a lower
> > layer than HTTP.
> >
>
> Well yes, sorry for being a bit too brief there, but an application level
> protocol which can be proxied is what it is about.
>
> > I'm only saying that a TCP/UDP based api would be useful.  I'm NOT saying
> > that security policies should allow SUCCESS at using the api though...
>
> In many such environments flash and java won't work either, yet it has
> always
> been a struggle to keep them out. If its possible, it will be used and the
> premise that browser based apps can work in such environments will be
> broken
> again (just as the dropping of support for such plugins was moving toward a
> situation where this could be reliably assumed)
>
> >
> > The hoops one must jump through to get a plain old stream connection
> > is very annoying.  Java or flash applets usually wound up having to
> > be written and I'd much rather just use javascript.  Javascript is
> > more transparent anyway and I'd rahter run a script than load an
> > unknown black box with flash or java in it.
>
> I certainly agree this would make a number of things easier, but in all
> fairness, with one simple addition at the server side (for which I used
> node.js, but it is not the only solution)


That, right there, is why I'm complaining.  The client side should be
flexible enough to be able to do stuff WITHOUT requiring the server to make
special accomodations or stuff.

With a server just running code you control yourself?  Yes, fair.  on the
internet in general?  Not so much, and quite frankly it's a hassle anyway
even on servers you control.

You should be able to do stuff *without* having to go through a silly
server-side process to HTTPify everything.


> and using the socket.io library, it
> all becomes rather transparent and trivial to do in javascript. You can
> still
> do all the binary transfers you like, through it will be tunneled over
> http,
> which satisfies the requirement above. Still no udp tho, thats a different
> story (but.. vanilla dgd also only has very restricted support for it for
> example)
>
> Also, http is ugly but it does address things like ensuring you know where
> messages start and end when things no longer fit in a single packet. You'll
> find you often need to replicate part of what it does to make transferring
> more then a few hundred bytes reliable (there may be shortcuts such as \0
> termination depending on exactly what data you want to transfer).
>
> Bart.
> --
> http://www.flickr.com/photos/mrobjective/
> http://www.om-d.org/
>
> ____________________________________________
> https://mail.dworkin.nl/mailman/listinfo/dgd
>