-
Notifications
You must be signed in to change notification settings - Fork 129
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Chat Message Container #766
Comments
Thanks @Yannick-Symphony this looks good. A couple of quick first thoughts:
|
Hi @kriswest !
|
Hi @Yannick-Symphony, I think this is likely to come up again (on notifications), so perhaps we should create a full context type for an 'action', e.g.: {
type: "fdc3.action",
title: "EUR/USD", //optional
intent: undefined, //optional, i.e. can be omitted to imply raiseIntentForContext rather than raiseIntent
context: { //required
type: 'fdc3.instrument',
id: {
ticker: 'EURUSD'
}
}
} However, I suppose there is also a use case for broadcasting that context on a user channel. That could be dealt with by a UI (just offer it as an a resolver option when displaying for Turning this into a full context would mean that I've only just noticed that entities is currently |
Later on, when we standardise a richer format for the text field, having a map with string keys will make referencing specific entities from within the text cleaner. e.g.
It might be wise to keep the flexibility to pass more than standardised fdc3 objects, especially if we want to integrate with generic messaging/email systems: we'll quickly need entity types like "fileAttachment", "inlineImage", "vcard" etc. In which case we'd better keep "entitites" and "entitytype" so does this match your vision?
example of the bare minimum - a context without title, app or intent:
|
Based on discussion in the intents and context meeting, it is slightly unclear from the use-case exactly what is being addressed here. Really, what we are trying to achieve is something like the "share" menu on your phone, where you are presented with a number of destinations (messages, email, WhatsApp) that can accept the shared data. It might be worth tidying up the Use Case: part of the description along these lines to make it clearer. |
Enhancement Request
Use Case:
This proposal describes an initial structure to contain the "message" part of our new messaging-related intents
The objective is to be as generic as possible, building something that not only makes sense for IM chat applications, but also for asynchronous channels such as email
We also want to be flexible: for the textual part of the message we use a record to map mime type to content, allowing us to start with the simplest possible type (plain text) whilst we discuss further enhancements (e.g. markdown). This also allows applications to send multiple types (e.g. always sending plain-text as a "fallback")
The second record maps "entities" to unique IDs. An entity could be something as simple as an image attachment (see first example below), or something more advanced like an fdc3 intent that the user wants to embed into the outgoing message (see second example). The ID will allow us to reference specific entities from specific locations within the text when defining more advanced text formats.
Contexts
Message
Message to be sent in the context of StartChat or SendChatMessage
Details
Example
Here is an example of a simple text message with attached PNG image. This type of message could very well be sent to an email client, as well as any IM app out there
Additional Information
#620
#765
The text was updated successfully, but these errors were encountered: