On Tue Dec 20 09:06:07 2011, Sergey Dobrov wrote:
We have the same disadvantages here:
I'm not convinced, but even if this is the case, it limits the scope.
1. node ACLs can't be used (but it can for filtering on destination
server)
I think they can, can't they?
2. all node items should be stored on this aggregation service (but
it
should not for filtering on destination server)
No, all items for the remote node only. So we're not forcing every
server to maintain a copy of your mood just to satisfy your
microblogging needs, which I think you would need if you enforced
local-only filtering.
To put it another way, there's no speculative item storage; it'd all
be done by request.
The only advantage here is that we can do that transparently and we
will
not break compatibility. Any other problems will be here in more
complex
shape.
Those are big advantages, in my book.
For a start, no existing users can use either case - they need to do
things using manual subscriptions. It occurs to me that a very simple
change - making manual subscriptions to PEP nodes cause the
notifications to be sent out using type='normal' rather than
type='headline' - would cause the manual subscriptions to send data
into offline storage, which is already quite an advantage.
But in general terms, PEP is done and deployed; changing it at all is
hard, changing it as radically as you propose is essentially a
non-starter. It seems to me that the PEP subset is simply not
sufficient for your needs; you need to use something more, whether
that's more XEP-0060 features, or some other, new, protocol. But
trying to change PEP because it doesn't fit your use-case is just not
going to work.
Dave.
--
Dave Cridland - mailto:[email protected] - xmpp:[email protected]
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
