Andre Garzia wrote:

> Devising your own binary file transfer protocol based purely on TCP
> sockets is a very tedious and error prone process that will get you
> no advantages unless you really have some special need that is not
> solved by any of the solutions that already exists.
>
> The easiest way to work around not being able to use FTP and friends,
> is with a simple HTTP server and a CGI on the server machine that has
> logic for receiving file uploads, then you simply use either libURL or
> TSNet to send the files.


When SuperCard introduced socket programming to the Mac xTalk world with its companion Marionette add-on, being young folk we got all excited about crafting custom protocols for every little thing we needed.

It was a good learning experience, and I came to appreciate the vast range of styles in writing clients for NNTP, Gnutella, and FTP, in addition to the random protocols I came up with on my own.

But the biggest lesson I learned is not to write custom protocols. :) It's a lot of work to get them working well, and far more work to make them secure and robust.

These days I rarely think about protocols at all, at least in customer-facing code. I've adopted using HTTP as the default solution for everything, unless I have a specific reason not to use it.

Most of what we need from a server is to submit a request and get a reply, and occasionally have some metadata along for the ride. HTTP does that well, with very slim header requirements that are also vastly extensible, so metadata is as simple or rich as you need in the moment. There's more documentation and tooling for HTTP than any other protocol, so it's easy to learn to use it well, and if another programming joins the team they can work with your code effortlessly.

Defaulting to HTTP for customer-facing systems simplifies a lot of decision-making, and since most of the rest of the world makes the same choice at least we're in good company. :)

--
Richard Gaskin
Fourth World Systems


_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Reply via email to