4 ms·

As someone who has been working on this for a very long, my advice is to write the software to be protocol agnostic. Be able to switch out protocols easily, an

As someone who has been working on this for a very long, my advice is to write the software to be protocol agnostic. Be able to switch out protocols easily, and support multiple protocols concurrently, because we still have no idea which protocol will win out. It may be something that hasn't even been built yet.

kenjackson 16y ago
I agree, but this is harder than it sounds. Why? If this is your first time building such a system you don't even know what is protocol and what's not. There's an old saying that you need to build three apps on your framework. That first app shows that your framework works for something. The second app shows that its more general than just the first app. The third app shows that you weren't lucky. Curious, how was Facebook designed? Are there any post-mortem docs on it? I know that MySpace seemed really ad hoc. I wouldn't be surprised if Facebook was more ad hoc than we imagine it to have been
- dasil003 16y ago
  How do you measure "more ad hoc"? The only software that's not ad hoc are huge enterprise projects that fail most of the time. If I had to guess I'd say that both MySpace and Facebook were completely ad hoc, but the difference was probably that Facebook kept their technical debt down so that they never accumulated an area of code that was too hairy to refactor or replace. MySpace on the other hand probably got complacent in their success and didn't worry too much as their architecture calcified into an unmaintainable mess. By the time they saw Facebook nipping at their heels their code base was past the point of no return, and the company culture made it impossible to hire the level of technical talent they would have needed to right the ship. Of course I'm completely talking out my ass here, but that's the impression given by the respective product histories.
- jacobolus 16y ago
  Who doesn’t imagine Facebook’s early design to be “ad hoc”? It was programmed as a spaghetti mess of PHP on Zuckerberg’s tiny laptop, and only worked because the user base was inherently limited to a few thousand people. Then the spaghetti mess was grown and added to over the next year or two, and the system scaled because each college’s network could be contained in a single server that only had to support a few thousand users (these servers used to use domain names like harvard.thefacebook.com or mit.thefacebook.com, IIRC). At some point they completely rewrote it with an architecture that would scale and not waste hardware, but it definitely didn’t start out that way.
  - kenjackson 16y ago
    Who doesn’t imagine Facebook’s early design to be “ad hoc”? Maybe just me. I don't know much about the history of the project, except Zuck started it in college.
neilk 16y ago
Perhaps I misunderstand you, but "protocol agnostic" is a red flag to me. SOAP was designed to be protocol agnostic (there were specs for SOAP-over-SMTP and XMPP and so on and so on) and look how that turned out. As the OP points out, protocol cannot be truly decoupled from architecture, especially when it comes to things like routing. There's a huge difference between a Twitter-like @user, an SMTP-like user@domain, a URL-based system like OpenID, etc.
- michaelchisari 16y ago
  There's always a trade off for just how agnostic you can be, so there's no way to support every possibility. But if you look at the different federated social web projects, there are clear similarities between them (ie, identity is in a username@domain format), so you can easily build around those similarities. For instance, building around events ("posting a status update", "sending a friend request", "verifying an identity") and abstracting out those events into hooks is how Appleseed does it. I have no misconceptions that this will hold up to every possible social protocol, past, present and future, but thinking about the protocol as an abstraction, and building the platform out from there, has already shown itself to be very useful.

kenjackson 16y ago

I agree, but this is harder than it sounds. Why? If this is your first time building such a system you don't even know what is protocol and what's not. There's an old saying that you need to build three apps on your framework. That first app shows that your framework works for something. The second app shows that its more general than just the first app. The third app shows that you weren't lucky. Curious, how was Facebook designed? Are there any post-mortem docs on it? I know that MySpace seemed really ad hoc. I wouldn't be surprised if Facebook was more ad hoc than we imagine it to have been

dasil003 16y ago
How do you measure "more ad hoc"? The only software that's not ad hoc are huge enterprise projects that fail most of the time. If I had to guess I'd say that both MySpace and Facebook were completely ad hoc, but the difference was probably that Facebook kept their technical debt down so that they never accumulated an area of code that was too hairy to refactor or replace. MySpace on the other hand probably got complacent in their success and didn't worry too much as their architecture calcified into an unmaintainable mess. By the time they saw Facebook nipping at their heels their code base was past the point of no return, and the company culture made it impossible to hire the level of technical talent they would have needed to right the ship. Of course I'm completely talking out my ass here, but that's the impression given by the respective product histories.
jacobolus 16y ago
Who doesn’t imagine Facebook’s early design to be “ad hoc”? It was programmed as a spaghetti mess of PHP on Zuckerberg’s tiny laptop, and only worked because the user base was inherently limited to a few thousand people. Then the spaghetti mess was grown and added to over the next year or two, and the system scaled because each college’s network could be contained in a single server that only had to support a few thousand users (these servers used to use domain names like harvard.thefacebook.com or mit.thefacebook.com, IIRC). At some point they completely rewrote it with an architecture that would scale and not waste hardware, but it definitely didn’t start out that way.
- kenjackson 16y ago
  Who doesn’t imagine Facebook’s early design to be “ad hoc”? Maybe just me. I don't know much about the history of the project, except Zuck started it in college.

neilk 16y ago

Perhaps I misunderstand you, but "protocol agnostic" is a red flag to me. SOAP was designed to be protocol agnostic (there were specs for SOAP-over-SMTP and XMPP and so on and so on) and look how that turned out. As the OP points out, protocol cannot be truly decoupled from architecture, especially when it comes to things like routing. There's a huge difference between a Twitter-like @user, an SMTP-like user@domain, a URL-based system like OpenID, etc.

michaelchisari 16y ago
There's always a trade off for just how agnostic you can be, so there's no way to support every possibility. But if you look at the different federated social web projects, there are clear similarities between them (ie, identity is in a username@domain format), so you can easily build around those similarities. For instance, building around events ("posting a status update", "sending a friend request", "verifying an identity") and abstracting out those events into hooks is how Appleseed does it. I have no misconceptions that this will hold up to every possible social protocol, past, present and future, but thinking about the protocol as an abstraction, and building the platform out from there, has already shown itself to be very useful.