On Wed Dec 14 16:54:55 2011, Sergey Dobrov wrote:
On 12/14/2011 10:39 PM, Dave Cridland wrote:
> On Wed Dec 14 12:51:22 2011, Sergey Dobrov wrote:
>> On 12/14/2011 07:19 PM, Dave Cridland wrote:
>> > On Wed Dec 14 11:53:50 2011, Sergey Dobrov wrote:
>> >
>> > You can query the PEP service and it'll tell you the
subscribed nodes,
>> > so you only need to store the services - in your described
scenario
>> > these services would be stored in your roster, which is
convenient.
>>
>> Store services in the roster instead of users? I think it's
ridiculous.
>
> Your scenario is that the client has a one-way subscription to a
contact
> and you want PEP stuff from this contact.
>
> Therefore, the contact is in your roster.
Yes, and I am receiving events on the end that doesn't have to
receive
them! Very useful!
I have no idea what you mean. You did say you had a subscription to
(but not from) the contact you wanted PEP stuff from. So that contact
will be in both rosters already. You can then list the manual
subscriptions, get any items you've missed, and so on. It does mean
doing manually what'll happen automatically with a subscription of
"both", but that's the penalty.
>
> The PEP service jid is the same as the contact's jid.
>
> Therefore, the PEP service is stored in your roster.
>
> Therefore, you are already being as ridiculous as is required.
Yeah. But you are missing all convenience and integrated approach of
xmpp. I can make some workarounds if I will get things work right
in the
future. But I think that if we will not notice such fundamental
problems
now then we will not be able to solve them in future because we will
have more and more underlying things. I understand that I, maybe,
ask
for some ambiguous things and ask too many things. But the
situation is:
I fight with juick.com that it doesn't follow XMPP standards at
all, it
doesn't want to find a ways to make things well support RFCs and
XEPs.
Then I start to work on my own project that will follow these
things and
I see that standards are not ready to use in real life projects. I
propose ways to solve these problems but I see that nobody wants to
solve them. I don't insist that my ways are ideal but I propose
something, at least. So it seems that I am completely lose: juick
works
but mine implementation can't do such simple thing as user
subscription.
But if we will look deeper: maybe it's a loss of XMPP itself?
But the standards you're talking about work in real-life projects
just fine. I don't know how many people routinely use PEP, but the
figures are hardly small.
What you're after is a presence-based subscription without having
presence, and that's bound to be problematic. Any way of avoiding a
bidirectional presence susbcription being involved is going to cause
other compromises to be made - these compromises may not matter to
you, but they certainly matter to others, and they're reductions
against what's possible now, so need a tremendous advantage to
outweigh them.
Maybe if you can explain precisely what your use-case is, then people
can provide you with explanations of how to achieve it with what we
have - and if not, then we can figure out what needs to be done.
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
