Comments (8)
How about "type"?
from sockethub.
Good call, thanks!
from sockethub.
Hmm, doesn't 'type' kind of imply "what is the type of address in this object?" which isn't quite what we want to express. Generally this field would not exist, only in the case for email, or something like it, where the email address related to a specific field somewhere.
I was updating the examples and it started to look like 'type' was supposed to describe what the address was. (ie. email, xmpp address, etc.) which is redundant since we have the platform properties.
I don't know, any thoughts?
from sockethub.
If we hadn't the platform properties we could still have a "type" for email, xmpp etc. That way the client can send messages without caring about the actual platform. A message sent to recipients on 3 platforms only needs to be sent once. Then the dispatcher would need to be able to figure out which platforms need to see the message in order for it to be delivered.
from sockethub.
So, you're basically saying the purpose of the platform property should be moved into the target object(s) and named 'type' ?
from sockethub.
i had multi-platform activities in my first pre-decessor of sockethub, but it didn't make any sense in practice. the app can just send several activities in the rare case that you have recipients on multiple platforms. also, it's tempting to continuously change the format, and it doesn't move the project forward in terms of getting stuff working. so i wouldn't go that route.
to make 'type' more descriptive, you can give it a longer name, like 'recipient-type'
from sockethub.
Yeah, i definitely do not want to change the behavior, and agree 100% we
can keep making changes all day long and never make any overall progress. I
was just trying to clarify what nilclass was suggesting.
Anyway, the term type (or even recipient type) still, to me, seems to
suggest the name of the service of the address. To me thats misleading. I
dont particularly like 'field' but it seems less misleading. Any other
ideas?
On Mar 6, 2013 4:37 AM, "Michiel@unhosted" [email protected]
wrote:
i had multi-platform activities in my first pre-decessor of sockethub, but
it didn't make any sense in practice. the app can just send several
activities in the rare case that you have recipients on multiple platforms.
also, it's tempting to continuously change the format, and it doesn't move
the project forward in terms of getting stuff working. so i wouldn't go
that route.to make 'type' more descriptive, you can give it a longer name, like
'recipient-type'—
Reply to this email directly or view it on GitHubhttps://github.com//issues/49#issuecomment-14480840
.
from sockethub.
Anyway, it seems what @nilclass was proposing was a new feature, not entirely related to the purpose of why I suggested a 'field' property.
I do see merrits in his suggestion, but it doesn't replace the need for the 'field' property. So I'm going to add that as initially described.
I agree with @michielbdejong that we don't need to stockpile commands into a single request. WebSocket traffic is cheap (no http headers) and it keeps thing simple and clear for the time being.
from sockethub.
Related Issues (20)
- Actor type is wrong for room presence updates HOT 2
- "credentials" message type throwing a validation error HOT 3
- Validate outgoing AS objects HOT 1
- Alert ahead of time when Redis isn't listening
- Tag and publish pre-release of 5.0 HOT 1
- Split sockethub package into sockethub and @sockethub/server HOT 1
- Improve linting
- Generate Sockethub config with command-line tool
- Sockethub shutting down instead of handling exception HOT 8
- Add option to force clients to provide a token for access
- Platform Idea: Readability
- Switch to yarn workspaces and lerna-lite?
- i can not 'yarn run start' HOT 8
- docker-compose build does not seem to work HOT 1
- `socket.io.js.map` 404
- Platform Idea: Discourse Chat HOT 1
- Do we need to still support Node 14.x ? HOT 2
- Switch to `pnpm` & use it's workspaces
- Sentry integration
- Add tooltips and more descriptive text in the examples package
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from sockethub.