Talk:The Socknet
From The Socknet
Contents |
TODO: Pull Out Optional Stuff
Some articles have optional sections in them. Those sections need to be pulled out into separate articles and listed under Optional on the Main Page.
--Dan 14:10, 1 October 2009 (UTC)
The Bandwidth Argument and Why We Don't Do It Like Email
SMTP has a nice feature in that, if you send the same email to several users on the same host, it can be sent once and directed at all of them.
Something like:
RCPT TO: dan@socknet.net, pati@socknet.net DATA blah blah blah .
This is nice and saves bandwidth. But email is strictly a message exchange system. Message exchange is just 1 of the Socknet's 3 objectives
The Socknet works differently:
- The recipient's name is [often] in the URL for the call, so it is impossible to list more than one of them (because the caller doesn't know which part of the URL is user-specific [or what it means] and which part is host-specific)
- Most calls assume a one-to-one connection, not one-to-many, thus data is often tailored for the recipient
However,
- Recipient information could be sent via HTTP headers instead of via the URL or request object.
- And messages can be changed and sent to different recipients by simply ignoring the option to send to many recipients at once.
So far,
- We have avoided defining new HTTP headers for simplicity
- And we haven't really worried about the bandwidth saved by sending to multiple recipients
But,
- HTTP headers aren't very complex
- And there are other benefits of sending to multiple recipients. Like the option to leave the recipients field blank and let the receiving host determine which recipients are friends.
Yet,
- The ability to issue a successful GET call from a browser becomes impossible when HTTP headers are required (though this only matters for testing)
- The issue of return values becomes complicated when many recipients are involved.
Help me out here. Should we use HTTP headers for this? Now is our only chance to change this integral aspect of the system.
Ultimately, I feel that changing the system to support multiple recipients is a mistake because it only makes sense for one aspect of our system (messaging, vs. friending and services) and is really just a nicety even for that part.
--Dan 04:30, 11 November 2009 (UTC)
TODO: Change function names to use _ instead of -
Change function names to use _ instead of -
(That was 03:42, 25 January 2010 Dan)
- Reason being that most programming languages use - to mean "minus" and it can't be part of a method name. We could use _ in those langauges and just "fudge" the _ into a - when making the HTTP call, but that might mess up functions that will be defined in the future. So we'd better just do it a good way right now. --Dan 15:25, 15 February 2010 (UTC)
Caching
HTTP has a Cache header that I had hoped to use to cache Socknet responses, but it is intended mainly for proxies and is usually only used with GET. It seems "abusive" to use it for POST responses (and many Socknet calls are made via POST). So we'd probably better create a cache field within the repsonses ourselves. It should store either a time in HTTP Date format or a number of minutes.
--Dan 15:14, 15 February 2010 (UTC)
TODO: Wait. Reverse that.
So far the documentation has been laid out in a way that seeks to encourage understanding and feedback. But that's not the best way to explain how to build one. The best way to go about building a Socknet provider is to go to All Functions by Name and start implementing.
So, the big TODO here is to create a new page specifically for each function and briefly explain what it does and requires. Then point it to the existing pages that explain it in depth.
I think this would greatly help some folks who are already interested in implementing their own providers.
--Dan 01:55, 23 June 2010 (UTC)
