Actually, to complement Sylvain's message, there are already ways to
do most of this in Laconica.
onInitializePlugin:
* check for plugin-specific meta data table, create if does not exist
onEndNoticeSave
* parse data
* post-process through whatever api
* save results to plugin-specific meta data table
What's missing is an onEndNoticeDisplay (or so, maybe contextual based
on the view [listing vs single dent view, etc) so we can show whatever
we need to (map, extra links, etc).
The current solution I'd have is to filter and overwrite $action-
>rendered (text data type in db) onStartNoticeSave, but I'm unsure
that's a pattern worth pushing for (although it has some advantages,
such as having this integration being automatically compatible with
any laconica client [which render hooks might not be]).
Suggestions? Ideas? Concerns?
Stephane Daury
On May 22, 2009, at 14:26, Sylvain Carle wrote:
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
