4 ms·

Fascinating. Dropbox is e first really popular "filesystem in the cloud" so it stands to reason that we are going to start to see services built on top of it. R

by macrael 16y ago

Fascinating. Dropbox is e first really popular "filesystem in the cloud" so it stands to reason that we are going to start to see services built on top of it. Rally, it is a piece of the old "everyone will have a server" dream. Except, instead of having to define as new protocol for evry service, you just use JSON over http. There is a lot of potential here, much can be made of a publicly available everywhere filesystme.

thwarted 16y ago
Except, instead of having to define as new protocol for evry service, you just use JSON over http. Why do people keep saying things like this? These are protocols, but they are at different levels. HTTP is the transport protocol, JSON is the serialization protocol, but you'd still need to define a protocol to communicate the content. What will the fields be named? How do you handle missing fields, which are the required ones? Will all data sources that list photos agree to naming the fields the same? And what about field metadata, and metadata for the field metadata? Maybe that can be avoided with namespacing. Now we have something as crappy as XML.
- true_religion 16y ago
  The frustration of XML can be divided into two parts: 1. The frustrating infrastructure build around it, such as SOAP which is anything but simple 2. The verbosity of the protocol itself which frustrates human readability which supposedly is a key feature of XML If we use JSON and avoid the infrastructure mistakes of XML (e.g. requiring huge amounts of boilerplate for RPC calls), then I think the native readability of JSON makes it a far better choice for serialization protocol than XML.
  - thwarted 16y ago
    Yeah, that's great, but my point was that HTTP+JSON solves the easiest part, not the part that actually needs to be done: creating an agreed upon format for the content being serialized (via JSON) and transported (via HTTP). When that was attempted with XML, it ended up with multiple query methods, multiple schemas, new and obscure transport wrappers (SOAP over SMTP, for example). Maybe we can avoid a Second System Effect now going forward... if XML was the Second System.
- cyrus_ 16y ago
  You're describing a type system.
sedachv 16y ago
"Rally, it is a piece of the old "everyone will have a server" dream. Except, instead of having to define as new protocol for evry service, you just use JSON over http." The key point isn't HTTP, it's synchronization. Rsync, git, and content-addressable storage in general are going to be the next big thing in the web. One of the exciting things about the "everyone has a server" idea (http://wiki.debian.org/FreedomBox http://wiki.debian.org/FreedomBox are working on it) is actually the move away from shitty one-way NATed HTTP and onto IPv6 and a full spectrum of two-way protocols. The other exciting thing is the wider deployment of encrypted traffic (although that's more the fault of Firesheep), and public-key cryptography (how else are you going to build distributed social apps?). "much can be made of a publicly available everywhere filesystme." This is what HTTP already does.

by macrael 16y ago

thwarted 16y ago

Except, instead of having to define as new protocol for evry service, you just use JSON over http. Why do people keep saying things like this? These are protocols, but they are at different levels. HTTP is the transport protocol, JSON is the serialization protocol, but you'd still need to define a protocol to communicate the content. What will the fields be named? How do you handle missing fields, which are the required ones? Will all data sources that list photos agree to naming the fields the same? And what about field metadata, and metadata for the field metadata? Maybe that can be avoided with namespacing. Now we have something as crappy as XML.

true_religion 16y ago
The frustration of XML can be divided into two parts: 1. The frustrating infrastructure build around it, such as SOAP which is anything but simple 2. The verbosity of the protocol itself which frustrates human readability which supposedly is a key feature of XML If we use JSON and avoid the infrastructure mistakes of XML (e.g. requiring huge amounts of boilerplate for RPC calls), then I think the native readability of JSON makes it a far better choice for serialization protocol than XML.
- thwarted 16y ago
  Yeah, that's great, but my point was that HTTP+JSON solves the easiest part, not the part that actually needs to be done: creating an agreed upon format for the content being serialized (via JSON) and transported (via HTTP). When that was attempted with XML, it ended up with multiple query methods, multiple schemas, new and obscure transport wrappers (SOAP over SMTP, for example). Maybe we can avoid a Second System Effect now going forward... if XML was the Second System.
cyrus_ 16y ago
You're describing a type system.

sedachv 16y ago

"Rally, it is a piece of the old "everyone will have a server" dream. Except, instead of having to define as new protocol for evry service, you just use JSON over http." The key point isn't HTTP, it's synchronization. Rsync, git, and content-addressable storage in general are going to be the next big thing in the web. One of the exciting things about the "everyone has a server" idea (http://wiki.debian.org/FreedomBox http://wiki.debian.org/FreedomBox are working on it) is actually the move away from shitty one-way NATed HTTP and onto IPv6 and a full spectrum of two-way protocols. The other exciting thing is the wider deployment of encrypted traffic (although that's more the fault of Firesheep), and public-key cryptography (how else are you going to build distributed social apps?). "much can be made of a publicly available everywhere filesystme." This is what HTTP already does.