On Mon, Jul 25, 2011 at 4:40 PM, Julian Leviston <[email protected]>wrote:

> I guess my question is... what's stopping an alternative, replacement,

backwardly-compatible protocol from taking over where http and https

leave off?


HTTP and HTTPS are not very good protocols if your goals relate to
low-latency, security, and composition.



And what would that protocol do?


Here's what the protocol I'm working on would do:

* chord/pastry/tapestry distributed replacement for DNS  (free us from
ICANN; easier configuration)
* identifiers for hosts = secure hash of RSA public key (easy validation,
ortho. to trust)
* logical connections (easier composition, independent disruption, potential
'restore' and use cache)
* logical objects - flat, usually opaque object identifier (favor object
capability security idioms)
* extensible protocol (just add objects); supports new overlays and network
abstractions.
* efficient orchestration; forward responses multiple steps without
centralized routing
* wait-free idioms, i.e. 'install' a new object then start using it - new
object references created locally
* reactive behaviors: focus on models involving continuous queries or
control.
* batching semantics - send multiple updates then 'apply' all at once.
* temporal semantics - send updates that apply in future.



One of the issues is surely the way our router-system structure is in
> place... if there was going to be a replacement for the web, it would *have*
> to end up being properly web based (down to the packet level)


I think if we replaced the protocols for the web, we'd still call it 'the
web', and it would therefore still be 'web-based'. ;-)

But we don't need to follow the same protocols we currently do.


>
> I simply hate the fact that if three people in my house request the front
> page of the financial times, our computers all have to go get it separately.
> Why don't the other two get it off the first one, or at the very least, off
> the router?
>

You're rather stingy with bandwidth. Maybe you should try a Squid
server. ;-)

Support for ad-hoc content distribution networks is designed into my
reactive demand programming model.


>
> We don't even have languages of intention - just languages of
> implementation. We're left to "abstract out" the intention from reading the
> implementation.
>

Have you ever used an executable specification language (such as Maude or
Coq)?

Regards,

Dave
_______________________________________________
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc

Reply via email to