I have the following use case I'm trying to make happen within Laconica
and would like to find a generic solution so it can be used in many
other contexts. I'm posting this to get some feedback on my thinking and
on how to do it.
= Specific use case =
Sylvain posts a message to identi.ca
"The weather is great in Montréal!"
On save, the message is passed to a pre-configured filter (place
detection in this case) and thru an API call to the configured web
service, detects that "Montréal" is a place with an ID or lat/lon. This
value returned by the API is stored in an "attachment" field with a
"Location" type.
When a user looks at this message on identi.ca, he sees and extra icon
(or label) with the message and can click on it to go to the source of
that extra info (or display inline).
= Generic use case =
A user posts a message to a laconica instance.
On save goes thru pre-configured "filters" and gets the result. It then
adds extra meta-data or content to the message, stored in a specific
"extended" field in the db. The system also assigns a type to that
attachment to the message body.
On query (via the api) or on display, the attachment is sent/displayed
according to it's type, with an action parameter to process if the user
takes a specific steps (click, etc).
= The way I see it =
Right now, a message (dent) has the following attributes (correct me if
I am wrong, I am deriving this from the UI and not the DB schema):
ID, User, time, body, source-client, in-reply-to
I would like to be able to add an attachment to a message, to extend
what is possible to store and display. This attachment could have a type
to provide specific processing instructions (on post, post-processing,
display).
The attachment could be a simple URL or an Text/XML chunk.
= What I would like to know =
This does not look to hard to implement and could be ignored by
instances where no filters are configured. We are ready to develop this
feature and submit the patches for it, but would prefer to have a
generic use case that is useful for everyone.
Attachment could of course be of any defined type, link, URL, VCARD,
microformatted chunk, etc.
Sounds useful? Anything I'm missing?
Of course we could model this after how attachment work in email
clients, there plenty of prior art there to get us started, but I would
not limit this only to what exists today.
--
Sylvain Carle / CTO @ Praized Media
http://identi.ca/afroginthevalley/
http://code.google.com/p/praized/
http://blogs.praized.com/dev/
_______________________________________________
Laconica-dev mailing list
[email protected]
http://mail.laconi.ca/mailman/listinfo/laconica-dev
