>Can we send a message to more than one pool? If I remember correctly a message can only be in one pool. Based on this restriction, it would only make sense to use the pool-linked functionality for actions with messages that originate in non-pools (for example, RSS feeds)
D. On Tue, Nov 10, 2009 at 3:41 PM, Ethan Jewett <[email protected]> wrote: > I forgot about the way messages are handled when resending. I like > newlines for adding pool and tag information to rss and atom actions. > > Everyone else agree that the "action" part of an action for atom or > rss should look like this?: > > atom:http://the.address.com/to/my/feed.atom > pool:My Pool > tags:test,myfeed,address.com > > Can we send a message to more than one pool? > > Ethan > > On Tue, Nov 10, 2009 at 9:31 AM, Vassil Dichev <[email protected]> wrote: >>> Just bumping this up again, as I kind of forgot about it. Vassil, what >>> would this syntax to specify a tag or pool for a new message look >>> like? I assume it would be different for resend vs. messages generated >>> from feeds. >> >> For an atom/RSS feed I imagine it could be specified with something >> like "pool:mypool" or "tags:tag1,tag2", separated by >> newline/whitespace/commas from the action definition >> "atom:http://server.org/whatever";, depending on how we want to >> separate several tags (spaces, commas). >> >> For resending messages this is problematic- messages are by design >> immutable, so we can't add/edit tags (this has been discussed in the >> past). Resending to another pool is also a security problem, as is >> explicitly indicated in the last design specification by Bill >> Fernandez. >> >> The important thing to remember is that a message is saved only >> *once*. A user's timeline consists only of references to messages, not >> of copies of messages. Thus there's a problem when you edit a message, >> because this will affect all users with this message in the timeline. >> This causes consistency problems on many levels, which could result in >> confusion for the users, undefined behavior to streaming clients when >> an old message is edited, and severe performance problems. >> >> So in short, for Atom/RSS the answer is easy, for resending I don't >> believe it will be implemented. >> >> Vassil >> >
