HyperText Transfer Protocol
Yeah yeah, you know about it. TBL and everything. The original HTTP was just... throw a connect at a host, tell him GET this or that, then you receive the file as is and the socket is closed, which means that all the time TCP needed to get its window size properly set was thrown away as for the next click a new connection is made.
HTTP was designed with an idea in mind, a vision, the same vision that led us to the URL (we call it a uniform) concept and the HTML. And yet over the years it got fixed up quite impressively and now even serves the job of a File Transfer protocol better than FTP (that's one of the reasons why we'd like to have an HTTP Server built into PsycZilla).
So what does this really have to do with PSYC? Well, as Larry Masinter suggested, psyced and the early WWW have one thing in common: they support most existing technologies, before coming up with a new one. That was easy with Gopher and WAIS, but won't be with IRC and XMPP. What else?
psyced comes with a builtin HTTP-Server that features a little CMS based on textdb. It is also a good framework for dynamic web applications, especially when they involve multi-user interaction or realtime aspects like pushing data and yes, even AJAX and Comet are fancy newer words for things that symlynX has been doing with psyced Webchat technology since 1997.
In psyced, persons can define content for their web profile and be customized using style sheets, so can places. With the advent of PsycZilla we even have web applications that do not use HTTP at all, because the HTML content is delivered directly via PSYC. This could lead to a truly Private Web.
the POST superhighway
For clients behind firewalls we are planning to support the POST superhighway as Jim Gettys once called it. I'll fill you in on the details at a later time, although symlynX servers already support it. Essentially, you can access any interface protocol from the HTTP port.
Scalability and the REST
Fundamentally HTTP's query/response architecture still gets in the way of bidirectional messaging a lot, even after keep-alive and pipelining have been introduced (which took a decade!). In exchange it offers caching and expiry logic, which so-called RESTful HTTP applications such as OStatus make use of.
For PSYC applications that aspect isn't very interesting, since PSYC models all data distribution in a publish/subscribe way, where everything you need is delivered to you as it happens, so you don't need to cache.
Also, the PSYC syntax has the advantage of letting you deliver complex data with multiple binary elements (encrypted data for example) in a single message, while HTTP requires you to introduce an actual syntax to convey complex data, popularely JSON or XML, both not being capable of raw binary data. In theory you could use HTTP headers for structured payload, but that's not the intended way of operation.
2011: Google improves on HTTP with SPDY
While some folks develop entire APIs on top of interserver HTTP exchanges.. see Activity for an example.. others realize that HTTP isn't fast enough even for its original purpose, let alone intense interserver traffic. Read about SPDY.
How to implement the web over PSYC