simplify target schema

[silverbucket]

for email, we have an overly complicated target schema:

"target" : [
  "to": [
    {
      "address": "user@example.com",
    }
  ],
  "cc": [
    {
      "address": "foo@bar.com"
    }
  ],
  "bcc": []
]

In other cases, however, this doesn't make any sense. Instead let's simplify this like so:

"target" : [  
  {
    "field": "to",
    "address": "user@example.com",
  },
  {
    "field": "cc",
    "address": "foo@bar.com"
  }
]

Suggestions for something other than 'field' would be welcome :) @nilclass @michielbdejong

[nilclass]

How about "type"?

[silverbucket]

Good call, thanks!

[silverbucket]

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?

[nilclass]

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.

[silverbucket]

So, you're basically saying the purpose of the platform property should be moved into the target object(s) and named 'type' ?

[michielbdejong]

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'

[silverbucket]

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" notifications@github.com
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
.

[silverbucket]

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.