[Standards] PEP inconsistency with presence subscription
Sergey Dobrov
https://support.process-one.net/browse/EJAB-1473
I have small microblogging experimental project based on XEP-277, when
user wants to read some user, he sends subscribe presence. Another user
automatically sends "subscribed" but he doesn't obliged to ask presence
in the answer if he doesn't want to read the user's blog. But the
situation will be reversed: the first user will not receive
notifications but the second will.
But the problem can't be solved because if contact have subscription
"from" then I can't see user's presence and hence it's capabilities too
and I can't generate events. But if subscription is "to", I see the
presence and caps and I can generate events BUT since the opponent has
not requested our subscription then, it's reasonable to say, that he's
not interested in receiving our events. So the situation just what isn't
needed and can't be solved with the current caps behavior.
--
With best regards,
Sergey Dobrov,
XMPP Developer and JRuDevels.org founder.
Sergey Dobrov
Kevin Smith
The behaviour here is pretty much by design - the PEP defaults are
there for mutually shared information (e.g. extended presence) between
people with mutual presence subs. If you want a one-sided approach,
using manual subscriptions instead of the caps-based magic seems like
a better fit.
/K
Sergey Dobrov
presences? I mean, most of protocols that based on PEP are just
extensions for simple presence mechanism and that's really unuseful that
it's impossible to use them in a sheaf with subscriptions. A PEP service
can't be implemented outside a jabber-server, so why we can't allow it
to follow "probe" presences?
Kevin Smith
Because sending probe presences isn't the same as sending available
presences - and if it was, it'd be a presence leak.
/K
Kevin Smith
> On 10/19/11 9:25 AM, "Kevin Smith" <ke...@kismith.co.uk> wrote:
>
>> The behaviour here is pretty much by design - the PEP defaults are
>> there for mutually shared information (e.g. extended presence) between
>> people with mutual presence subs. If you want a one-sided approach,
>> using manual subscriptions instead of the caps-based magic seems like
>> a better fit.
>
> subscription using a caps hash:
>
> <iq type='set'
> from='fran...@denmark.lit/barracks'
> to=' jul...@capulet.lit'
> id='sub1'>
> <pubsub xmlns='http://jabber.org/protocol/pubsub'>
> <subscribe node='urn:xmpp:explicit' jid='fran...@denmark.lit/work'/>
> <options>
> <x xmlns='jabber:x:data' type='submit'>
> <field var='http://jabber.org/protocol/caps'>
> <value>zHyEOgxTrkpSdGcQKH8EFPLsriY=</value>
> </field>
> </x>
> </options>
> </pubsub>
> </iq>
>
> This would subscribe francisco to all of the authorized +subscribe features
> pointed to by the hash.
That seems fine to me.
/K
Sergey Dobrov
someone's status, so why we can't give our caps?
Sergey Dobrov
with the "to" subscription state?
Dave Cridland
Indeed, and then you may as well send them presence anyway.
Dave.
--
Dave Cridland - mailto:da...@cridland.net - xmpp:d...@dave.cridland.net
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
Sergey Dobrov
participation. And it's good from the point of traffic economy view. As
I can understand, the central target of entity capabilities is to
minimize client's traffic. So we lose two important things at one
moment: inconveniently send that thing by hand and serious increase of
user's traffic.
Other way is to send such stanza by server when client is connected. But
I can't understand what's the difference with presence probe in such
case. I will be glad if you will help me to understand.
Dave Cridland
> The difference is that presence will be sent by server without
> client's
> participation. And it's good from the point of traffic economy
> view. As
> I can understand, the central target of entity capabilities is to
> minimize client's traffic. So we lose two important things at one
> moment: inconveniently send that thing by hand and serious increase
> of
> user's traffic.
>
> Other way is to send such stanza by server when client is
> connected. But
> I can't understand what's the difference with presence probe in such
> case. I will be glad if you will help me to understand.
<presence from='d...@dave.cridland.net' to='bin...@jrudevels.org'
type='probe'/>
versus
<presence from='d...@dave.cridland.net/Gajim'
to='bin...@jrudevels.org'>
<c xmlns='...' .../>
</presence>
The main differences:
a) Probes are sent from the bare jid.
b) Probes don't have an unavailable equivalent, needed to later
remove the subscription.
c) Probes don't have the caps inside.
For PEP to work, the PEP service needs to know all three of those, so
basically it needs your presence - or a functional equivalent of it.
Sergey Dobrov
> On Wed Oct 19 19:27:01 2011, Sergey Dobrov wrote:
>> The difference is that presence will be sent by server without client's
>> participation. And it's good from the point of traffic economy view. As
>> I can understand, the central target of entity capabilities is to
>> minimize client's traffic. So we lose two important things at one
>> moment: inconveniently send that thing by hand and serious increase of
>> user's traffic.
>>
>> Other way is to send such stanza by server when client is connected. But
>> I can't understand what's the difference with presence probe in such
>> case. I will be glad if you will help me to understand.
>
> <presence from='d...@dave.cridland.net' to='bin...@jrudevels.org'
> type='probe'/>
>
> versus
>
> <presence from='d...@dave.cridland.net/Gajim' to='bin...@jrudevels.org'>
> <c xmlns='...' .../>
> </presence>
>
> The main differences:
>
> a) Probes are sent from the bare jid.
>
> b) Probes don't have an unavailable equivalent, needed to later remove
> the subscription.
>
> c) Probes don't have the caps inside.
>
> For PEP to work, the PEP service needs to know all three of those, so
> basically it needs your presence - or a functional equivalent of it.
I see the problem only in the "a" case. So the only way to solve that is
to send iq subscriptions by user's server?
>
> Dave.
Dave Cridland
> On 10/20/2011 03:56 AM, Dave Cridland wrote:
> > a) Probes are sent from the bare jid.
> >
> > b) Probes don't have an unavailable equivalent, needed to later
> remove
> > the subscription.
> How this solved for regular presences?
>
>
to go away (technically, for the PEP subscription filter to be
disabled).
> >
> > c) Probes don't have the caps inside.
> >
> > For PEP to work, the PEP service needs to know all three of
> those, so
> > basically it needs your presence - or a functional equivalent of
> it.
> I see the problem only in the "a" case. So the only way to solve
> that is
> to send iq subscriptions by user's server?
>
>
What you need is for the PEP service to know when you're online, and
know when you go offline. It also needs to know the caps of the
client that's involved.
This is all done by presence, in XMPP.
If you do it as an <iq/> based filtered subscription as Joe proposed,
then you still give out the same information, you're just no longer
calling it presence. I think that's actually more dangerous, because
it's slipping the same information by the back door and is very
likely to end up causing unpleasant surprises.
If you want a fixed subscription - that is, you want the events sent
to you whever the owner posts a message, whether or not you're
online, etc - then the existing subscription mechanism works fine.
Sergey Dobrov
> On Thu Oct 20 09:19:06 2011, Sergey Dobrov wrote:
>> On 10/20/2011 03:56 AM, Dave Cridland wrote:
>> > a) Probes are sent from the bare jid.
>> >
>> > b) Probes don't have an unavailable equivalent, needed to later remove
>> > the subscription.
>> How this solved for regular presences?
>>
>>
> You get a later type='unavailable', which causes the PEP subscription to
> go away (technically, for the PEP subscription filter to be disabled).
>
presence, then we receive remote user status. How remote server can know
that it can stop to send presences?
>
>> >
>> > c) Probes don't have the caps inside.
>> >
>> > For PEP to work, the PEP service needs to know all three of those, so
>> > basically it needs your presence - or a functional equivalent of it.
>> I see the problem only in the "a" case. So the only way to solve that is
>> to send iq subscriptions by user's server?
>>
>>
> What you need is for the PEP service to know when you're online, and
> know when you go offline. It also needs to know the caps of the client
> that's involved.
>
> This is all done by presence, in XMPP.
>
> If you do it as an <iq/> based filtered subscription as Joe proposed,
> then you still give out the same information, you're just no longer
> calling it presence. I think that's actually more dangerous, because
> it's slipping the same information by the back door and is very likely
> to end up causing unpleasant surprises.
>
> If you want a fixed subscription - that is, you want the events sent to
> you whever the owner posts a message, whether or not you're online, etc
> - then the existing subscription mechanism works fine.
The problem with that is that we will have two desynchronized rosters.
For example, I use two clients, the first supports PEP and the second
doesn't. I subscribe to some user via the second client and then the
client subscribes to it's PEPs, then I will receive extra traffic on the
first client even when I can't use that and if I unsubscribed from the
use via the first client then I will receive that notification even when
I have no subscription from the user. That things will make clients too
complex. So I think that this problem must be solved on the server side
and transparently for clients.
Sergey Dobrov
destiny predetermined? I really blocked by this bug and have to make a
choice to follow XSF's documents or drop them and build my own system.
On 09/27/2011 11:35 PM, Sergey Dobrov wrote:
Sergey Dobrov
receiver's server side and not on sender's side. I understand that it
will break compatibility and will no work if receiver's sender doesn't
support PEP but it will be more efficiently because server will no more
need to store all users capabilities, it can store only capabilities of
it's own users. Also, events can be sent only once to bare jid and not
to each full jid, etc.
On 09/27/2011 11:35 PM, Sergey Dobrov wrote:
Dave Cridland
> Guys, don't you think that it might be reasonable to filter
> messages on
> receiver's server side and not on sender's side. I understand that
> it
> will break compatibility and will no work if receiver's sender
> doesn't
> support PEP but it will be more efficiently because server will no
> more
> need to store all users capabilities, it can store only
> capabilities of
> it's own users. Also, events can be sent only once to bare jid and
> not
> to each full jid, etc.
OK, so let's assume that we want to try this:
1) First things first, we need to signal support for this. I suppose
this means that we need to do feature checks via disco for all the
subscribers - that is, when we receive a valid probe, we then need to
check the features of their server. Server-caps could help with this.
This removes one of the showstoppers you mention above.
2) We're also going to need to resend the last item when the
subscriber comes online. This is problematic for the node owner's
server, because receiving a probe doesn't actually indicate an online
event. The only alternative I see is that the subscriber's server
needs to store the last item for all the owner's nodes. Note, too,
that this needs to happen for all nodes, whether or not the
subscriber has ever needed the item (ie, whether or not the
subscriber is actually subscribed).
3) Finally, the subscriber's server will need to track retractions,
and all retractions made on the owner's server will need to send an
event out (ie, we must mandate notify-retract).
This covers us - just - for basic PEP. However, there have been
suggestions of using PEP in a more advanced way, for example sending
more than just the last item on reconnect. This would mean signalling
this back to the subscriber, and the subscriber's server maintaining
a shadow copy of all the items.
Some figures:
The incumbent protocol supports a caps cache which tends to be less
than the number of contacts total; but this caps cache can be used
for other things. (See my disco caching thing).
Your replacement looks to my eyes to have a caps cache, this time of
servers, which is likely to be markedly smaller. Hoorah, a saving.
But it also needs to maintain a cache of at least one item per PEP
node of the contacts, which seems very worrying.
I don't see this as an improvement, especially given the other
downsides you've previously highlighted.
You could mitigate this by discarding the send-last requirement, but
I don't think this is viable, and it's certainly less viable than
requiring either presence sharing or a manual subscription.
Finally, it also breaks if PEP nodes have a non-uniform ACL, of
course.
So while the advantages you state are pretty clear, I don't see a way
around the problems.
Sergey Dobrov
answer and I have some things to say but I understood that all this
conversation is unnecessary till we don't have an answer how "from"
subscription should work with simple presence. I described the problem
in neighborhood thread and I had an experiment that proves that such
subscriptions don't work well on the ejabberd's example. Could you say
me where am I wrong and if that problem is in ejabberd and not in the
protocol itself? Maybe you know which server should I test to give well
results? I learned the RFC but I can't find the answer there. Examples
are too simple in it and don't cover such complex cases.
Sergey Dobrov
>> Guys, don't you think that it might be reasonable to filter messages on
>> receiver's server side and not on sender's side. I understand that it
>> will break compatibility and will no work if receiver's sender doesn't
>> support PEP but it will be more efficiently because server will no more
>> need to store all users capabilities, it can store only capabilities of
>> it's own users. Also, events can be sent only once to bare jid and not
>> to each full jid, etc.
Okay, it's obvious now that the main difference between regular
presences and PEPs is in filtering messages feature. I really don't see
more natural way to solve the problem instead of move filtering on
receiver's server. Any other way will mean a leak of user's presence. We
can allow it if we will think that servers will no transmit this
information to the clients but we can't be sure in it. Please tell me if
you think that it's ok to solve problem in the way of translate user's
caps to the other side like it was offered earlier.
I don't know if you agree with me that the problem must be solved. But I
will think that you are by default because this conversation is
senseless if not. If you are not agree please tell me, I will try to
explain my point of view to the problem. Now, I will continue.
>
> OK, so let's assume that we want to try this:
>
> 1) First things first, we need to signal support for this. I suppose
> this means that we need to do feature checks via disco for all the
> subscribers - that is, when we receive a valid probe, we then need to
> check the features of their server. Server-caps could help with this.
> This removes one of the showstoppers you mention above.
>
> 2) We're also going to need to resend the last item when the subscriber
> comes online. This is problematic for the node owner's server, because
> receiving a probe doesn't actually indicate an online event. The only
> alternative I see is that the subscriber's server needs to store the
> last item for all the owner's nodes. Note, too, that this needs to
> happen for all nodes, whether or not the subscriber has ever needed the
> item (ie, whether or not the subscriber is actually subscribed).
There is some other kind of problem I see in pubsub:
I don't understand why properties like "send retract items" or "send
last item" are in node's properties and not in the subscription
properties. Since the necessity of these notifications depends on client
needs. For example, if I have microblogging service and my client has a
possibility to show new messages but have not a possibility to remove
posts from a feed then, probably, I don't need to receive retracts for
these nodes but I can't suppress them.
So, I think that the problem can be solved by reusing server's offline
storage. Server just will need to store some meta information for the
message and then it can not remove some messages from it's spool when it
sends the message and so it will resend the event each time user connected.
>
> 3) Finally, the subscriber's server will need to track retractions, and
> all retractions made on the owner's server will need to send an event
> out (ie, we must mandate notify-retract).
Since the filtering is not in a care of senders server I don't see the
problem in it at all.
>
> This covers us - just - for basic PEP. However, there have been
> suggestions of using PEP in a more advanced way, for example sending
> more than just the last item on reconnect. This would mean signalling
> this back to the subscriber, and the subscriber's server maintaining a
> shadow copy of all the items.
I can't imagine why it can be needed. Maybe you can give me a link with
explanation or something?
>
> Some figures:
>
> The incumbent protocol supports a caps cache which tends to be less than
> the number of contacts total; but this caps cache can be used for other
> things. (See my disco caching thing).
>
> Your replacement looks to my eyes to have a caps cache, this time of
> servers, which is likely to be markedly smaller. Hoorah, a saving. But
> it also needs to maintain a cache of at least one item per PEP node of
> the contacts, which seems very worrying.
The offline storage is saved on disk in database but caps cache is
stored in memory to provide better performance. I don't think that the
disk is a bottleneck for the present time.
>
> I don't see this as an improvement, especially given the other downsides
> you've previously highlighted.
>
> You could mitigate this by discarding the send-last requirement, but I
> don't think this is viable, and it's certainly less viable than
> requiring either presence sharing or a manual subscription.
>
> Finally, it also breaks if PEP nodes have a non-uniform ACL, of course.
What do you mean?
>
> So while the advantages you state are pretty clear, I don't see a way
> around the problems.
>
> Dave.
--
Kevin Smith
> On 12/09/2011 07:59 PM, Dave Cridland wrote:
>> On Fri Dec 9 12:18:14 2011, Sergey Dobrov wrote:
>>> Guys, don't you think that it might be reasonable to filter messages on
>>> receiver's server side and not on sender's side. I understand that it
>>> will break compatibility and will no work if receiver's sender doesn't
>>> support PEP but it will be more efficiently because server will no more
>>> need to store all users capabilities, it can store only capabilities of
>>> it's own users. Also, events can be sent only once to bare jid and not
>>> to each full jid, etc.
>
> Okay, it's obvious now that the main difference between regular
> presences and PEPs is in filtering messages feature. I really don't see
> more natural way to solve the problem instead of move filtering on
> receiver's server. Any other way will mean a leak of user's presence. We
> can allow it if we will think that servers will no transmit this
> information to the clients but we can't be sure in it. Please tell me if
> you think that it's ok to solve problem in the way of translate user's
> caps to the other side like it was offered earlier.
Having the receiving server filter pubsub is not going to work for a
number of reasons, including:
* It needs to cache every (+notify) pubsub node, everywhere that any
user of the server may ever see one. Storing what amounts to a local
copy of all remote pubsub servers isn't viable.
* The receiving server does not know what ACL should be being applied
to the node items, so is not able to correctly distribute the items.
* [Not an impossible failing but heavily undesirable] This generates
something of a bandwidth explosion.
If you want to be able to use pubsub without mutual presence
subscriptions I suggest using one of the other subscription types
instead of the presence-based +notify magic, which relies on
presesence.
/K
Dave Cridland
> Okay, it's obvious now that the main difference between regular
> presences and PEPs is in filtering messages feature. I really don't
> see
> more natural way to solve the problem instead of move filtering on
> receiver's server. Any other way will mean a leak of user's
> presence. We
> can allow it if we will think that servers will no transmit this
> information to the clients but we can't be sure in it. Please tell
> me if
> you think that it's ok to solve problem in the way of translate
> user's
> caps to the other side like it was offered earlier.
>
> I don't know if you agree with me that the problem must be solved.
> But I
> will think that you are by default because this conversation is
> senseless if not. If you are not agree please tell me, I will try to
> explain my point of view to the problem. Now, I will continue.
I offered a strawman solution to your stated problem, and described
why I thought that it was infeasable. So I don't think the problem
can be solved. Would it be nice to solve? Maybe. Not on my list of
critical problems, though.
There are, I think, a multitude of cases where XMPP essentially
relies on two-way subscriptions, I don't think this is a problem we
can solve at this stage.
> I don't understand why properties like "send retract items" or "send
> last item" are in node's properties and not in the subscription
> properties. Since the necessity of these notifications depends on
> client
> needs. For example, if I have microblogging service and my client
> has a
> possibility to show new messages but have not a possibility to
> remove
> posts from a feed then, probably, I don't need to receive retracts
> for
> these nodes but I can't suppress them.
OK, so that's perfectly reasonable, but also you can't change those
properties without effectively having a manual subscription anyway.
Manual subscriptions bypass your stated problem. I also suspect
they're incompatible with my strawman design.
> So, I think that the problem can be solved by reusing server's
> offline
> storage. Server just will need to store some meta information for
> the
> message and then it can not remove some messages from it's spool
> when it
> sends the message and so it will resend the event each time user
> connected.
>
>
I think you're describing a possible implementation, but it makes no
difference to the outcome - the data, whether or not it is to be
used, will still need to be stored, irrespective of whether you try
to unify storage facilities.
> >
> > 3) Finally, the subscriber's server will need to track
> retractions, and
> > all retractions made on the owner's server will need to send an
> event
> > out (ie, we must mandate notify-retract).
>
> Since the filtering is not in a care of senders server I don't see
> the
> problem in it at all.
>
>
Retractions currently need not be broadcast; I don't think this is a
fatal flaw, by any means, but I noted it as a part of the changes
required, and it's a further example of the kinds of the impact that
are forced on PEP by these changes.
> >
> > This covers us - just - for basic PEP. However, there have been
> > suggestions of using PEP in a more advanced way, for example
> sending
> > more than just the last item on reconnect. This would mean
> signalling
> > this back to the subscriber, and the subscriber's server
> maintaining a
> > shadow copy of all the items.
>
> I can't imagine why it can be needed. Maybe you can give me a link
> with
> explanation or something?
>
>
I think you're seeing PEP as a cut-down PubSub service; it's not. It
has a relatively small number of mandatory features, a mandatory set
of defaults, and it can be limited to those - however it needn't be.
Using collections, manual susbcriptions, and other XEP-0060 features
on PEP nodes and sevrices seems like a fine idea to me with many
interesting use-cases. I don't know why you'd want to prevent these.
> The offline storage is saved on disk in database but caps cache is
> stored in memory to provide better performance. I don't think that
> the
> disk is a bottleneck for the present time.
>
>
I have no idea what you may be implying here. One implementation may
indeed store offline messages (and, following on from your previous
suggestion, PEP items) in a database or similar disk-based storage,
but that's an implementation detail. In any event, this will be a
markedly higher level of storage than for offline messages; in
particular we can assume that each contact will be generating
multiple items due to multiple active PEP nodes. I just don't see why
this would not incur a performance impact.
> > Finally, it also breaks if PEP nodes have a non-uniform ACL, of
> course.
>
> What do you mean?
>
>
I mean it also breaks if PEP nodes differ in their configuration, in
the general sense, and particularly if they differ with respect to
access control.
PEP nodes have a default configuration, but some clients can,
already, change the configuration of particular nodes, and it's
really not clear how this would effect the strawman design I've
outlined.
Sergey Dobrov
> On Wed, Dec 14, 2011 at 9:23 AM, Sergey Dobrov <bin...@jrudevels.org> wrote:
>> On 12/09/2011 07:59 PM, Dave Cridland wrote:
>>> On Fri Dec 9 12:18:14 2011, Sergey Dobrov wrote:
>>>> Guys, don't you think that it might be reasonable to filter messages on
>>>> receiver's server side and not on sender's side. I understand that it
>>>> will break compatibility and will no work if receiver's sender doesn't
>>>> support PEP but it will be more efficiently because server will no more
>>>> need to store all users capabilities, it can store only capabilities of
>>>> it's own users. Also, events can be sent only once to bare jid and not
>>>> to each full jid, etc.
>>
>> Okay, it's obvious now that the main difference between regular
>> presences and PEPs is in filtering messages feature. I really don't see
>> more natural way to solve the problem instead of move filtering on
>> receiver's server. Any other way will mean a leak of user's presence. We
>> can allow it if we will think that servers will no transmit this
>> information to the clients but we can't be sure in it. Please tell me if
>> you think that it's ok to solve problem in the way of translate user's
>> caps to the other side like it was offered earlier.
>
> Having the receiving server filter pubsub is not going to work for a
> number of reasons, including:
>
> * It needs to cache every (+notify) pubsub node, everywhere that any
> user of the server may ever see one. Storing what amounts to a local
> copy of all remote pubsub servers isn't viable.
I don't understand why to do that. It can store just the last one to
store it in it's offline storage. I don't see an overhead here, servers
store offline messages for long time ago.
> * The receiving server does not know what ACL should be being applied
> to the node items, so is not able to correctly distribute the items.
It doesn't need to know anything about ACLs. Sender will just send to
bare JIDs, only for allowed JIDs.
> * [Not an impossible failing but heavily undesirable] This generates
> something of a bandwidth explosion.
I not agree. I think that it will decrease a bandwith, at least S2S
since we have not to send each event to each resource, we have not to
send last item through S2S each time new resource connected.
>
> If you want to be able to use pubsub without mutual presence
> subscriptions I suggest using one of the other subscription types
> instead of the presence-based +notify magic, which relies on
> presesence.
For example? Obviously, I can subscribe to nodes directly but where to
store the list of subscribed nodes? I think that this problem must be
definitely solved since it breaks a PEP idea at all.
>
> /K
Dave Cridland
> I don't understand why to do that. It can store just the last one to
> store it in it's offline storage. I don't see an overhead here,
> servers
> store offline messages for long time ago.
>
>
> > * The receiving server does not know what ACL should be being
> applied
> > to the node items, so is not able to correctly distribute the
> items.
>
> It doesn't need to know anything about ACLs. Sender will just send
> to
> bare JIDs, only for allowed JIDs.
>
>
It's not clear to me that ACLs are irrelevant here. But I'll concede
they could be.
Irrespective of this, other node configuration issues probably will
have a marked effect.
> > * [Not an impossible failing but heavily undesirable] This
> generates
> > something of a bandwidth explosion.
>
> I not agree. I think that it will decrease a bandwith, at least S2S
> since we have not to send each event to each resource, we have not
> to
> send last item through S2S each time new resource connected.
>
>
It depends on whether the last item saving and per-resource saving
outweighs the number of irrelevant items sent.
This in turn depends on a number of things, including publish
frequency, number of resources, and so on. I would note that the
saving by number of resources is likely to be very small - most
contacts will only have one resource. So the real saving in bandwidth
will be whether the number of offline/online events outweighs the
number of updates sent when the contact is offline.
> > If you want to be able to use pubsub without mutual presence
> > subscriptions I suggest using one of the other subscription types
> > instead of the presence-based +notify magic, which relies on
> > presesence.
>
> For example? Obviously, I can subscribe to nodes directly but where
> to
> store the list of subscribed nodes? I think that this problem must
> be
> definitely solved since it breaks a PEP idea at all.
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.
Sergey Dobrov
Store services in the roster instead of users? I think it's ridiculous.
>
> Dave.
Dave Cridland
> 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.
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.
Sergey Dobrov
> 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!
>
> 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?
Dave Cridland
> 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!
>
>
(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.
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.
Sergey Dobrov
> 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.
>
I meant that if I have a contact in my roster with "from" subscription
then I will receive it's events but I don't want to receive them because
I did not request it's subscription. I have to filter them additional on
client side? Strange way...
Ok, the task is easy: I have microblogging service based on some subset
of XEP-277. To subscribe to the user's blog I request user's
subscription. My client will automatically accept any subscription
request to allow any user to read it's blog. User will see a notify that
someone subscribed to him and probably will subscribe too. But if user
will not subscribe, he will have reversed behavior: he will receive blog
entries but user who subscribed to him will not. It's very useful to use
regular subscriptions for that case because I don't need to maintain the
list of subscriptions, I can use roster in regular way: to chat and see
statuses, I can allow clients to use regular jabber clients to use them
accounts to chat. Many many benefits here. But if I will maintain PEP
subscriptions separately then user will be able to remove any contact
using regular jabber client but it will not remove pubsub subscription
to it's blog and then there will be a real hell and desynchronize.
I already told that most XEPs based on PEP now are just extended
statuses (moods/activity,something) and it's really strange when user
have a contact with "to" subscription but can't see it's mood or
something. I understand that it's not often case when regular jabber
user have "to" subscription (but I have many such contacts, for example)
but I think that such thing may be a really big problem for some
applications (like mine).
About compromises. I think that we have to discuss them. I did not hear
any thing that is impossible to solve yet. But I know, for example, that
jabber.ru implementation of PEP don't filter any PEP messages at all!
Because of lot memory consumption. So I see that PEP is not work too
good as it seems in real life.
Dave Cridland
> I meant that if I have a contact in my roster with "from"
> subscription
> then I will receive it's events but I don't want to receive them
> because
> I did not request it's subscription. I have to filter them
> additional on
> client side? Strange way...
>
>
presence.
If you have a subscription 'to', then you don't have PEP events,
because those are presence based (and you're not sending presence).
But you can use these to handle the item retrieval and maintain
manual subscriptions.
Actually no - if the access-model of the node is set to presence (as
is the default), then the manual subscription ought to be removed
when the user unsubscribes from the contact.
> I already told that most XEPs based on PEP now are just extended
> statuses (moods/activity,something) and it's really strange when
> user
> have a contact with "to" subscription but can't see it's mood or
> something. I understand that it's not often case when regular jabber
> user have "to" subscription (but I have many such contacts, for
> example)
> but I think that such thing may be a really big problem for some
> applications (like mine).
>
>
It's presence-based susbcription. You're only subscribed when you
send the presence, in effect.
> About compromises. I think that we have to discuss them. I did not
> hear
> any thing that is impossible to solve yet. But I know, for example,
> that
> jabber.ru implementation of PEP don't filter any PEP messages at
> all!
> Because of lot memory consumption. So I see that PEP is not work too
> good as it seems in real life.
I would note there are plenty of implementations that filter
properly, so I wouldn't say it's an impossible thing to do. Some of
these run quite big deployments.
Sergey Dobrov
> On Thu Dec 15 12:54:28 2011, Sergey Dobrov wrote:
>> I meant that if I have a contact in my roster with "from" subscription
>> then I will receive it's events but I don't want to receive them because
>> I did not request it's subscription. I have to filter them additional on
>> client side? Strange way...
>>
>>
> If you have a subscription 'from', then you won't receive any PEP or
> presence.
I am receiving them when from subscription. I will never say before check.
>
> If you have a subscription 'to', then you don't have PEP events, because
> those are presence based (and you're not sending presence). But you can
> use these to handle the item retrieval and maintain manual subscriptions.
>
And will increase traffic for clients which don't support microblogging.
The PEP protocol is again loss. The things that it was designed for are
work well only for very simple protocols like moods.
>> > 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.
>>
>> Ok, the task is easy: I have microblogging service based on some subset
>> of XEP-277. To subscribe to the user's blog I request user's
>> subscription. My client will automatically accept any subscription
>> request to allow any user to read it's blog. User will see a notify that
>> someone subscribed to him and probably will subscribe too. But if user
>> will not subscribe, he will have reversed behavior: he will receive blog
>> entries but user who subscribed to him will not. It's very useful to use
>> regular subscriptions for that case because I don't need to maintain the
>> list of subscriptions, I can use roster in regular way: to chat and see
>> statuses, I can allow clients to use regular jabber clients to use them
>> accounts to chat. Many many benefits here. But if I will maintain PEP
>> subscriptions separately then user will be able to remove any contact
>> using regular jabber client but it will not remove pubsub subscription
>> to it's blog and then there will be a real hell and desynchronize.
>>
>>
> Actually no - if the access-model of the node is set to presence (as is
> the default), then the manual subscription ought to be removed when the
> user unsubscribes from the contact.
>
Ok, will check that.
>
>> I already told that most XEPs based on PEP now are just extended
>> statuses (moods/activity,something) and it's really strange when user
>> have a contact with "to" subscription but can't see it's mood or
>> something. I understand that it's not often case when regular jabber
>> user have "to" subscription (but I have many such contacts, for example)
>> but I think that such thing may be a really big problem for some
>> applications (like mine).
>>
>>
> It's presence-based susbcription. You're only subscribed when you send
> the presence, in effect.
>
>
>> About compromises. I think that we have to discuss them. I did not hear
>> any thing that is impossible to solve yet. But I know, for example, that
>> jabber.ru implementation of PEP don't filter any PEP messages at all!
>> Because of lot memory consumption. So I see that PEP is not work too
>> good as it seems in real life.
>
> I would note there are plenty of implementations that filter properly,
> so I wouldn't say it's an impossible thing to do. Some of these run
> quite big deployments.
May I ask about examples of such software and deployments? I am worrying
about high load too.
Also, I wanted to ask about big solutions which uses PEP/Pubsub in real
life applications to learn how them work.
Dave Cridland
> On 12/16/2011 01:02 AM, Dave Cridland wrote:
> > On Thu Dec 15 12:54:28 2011, Sergey Dobrov wrote:
> >> I meant that if I have a contact in my roster with "from"
> subscription
> >> then I will receive it's events but I don't want to receive them
> because
> >> I did not request it's subscription. I have to filter them
> additional on
> >> client side? Strange way...
> >>
> >>
> > If you have a subscription 'from', then you won't receive any PEP
> or
> > presence.
>
> I am receiving them when from subscription. I will never say before
> check.
>
>
owner has changed the access-model from the default (possible, but
unusual).
The specification clearly states that the default access model for
PEP ndoes is 'presence', and the presence access model only allows a
subscription for contacts in the owner's roster of 'from' or 'both'
(correspondingly, the contact will have the node owner as 'to' or
'both').
So if you have the contact as 'from', in the typical case you should
not be getting PEP events.
> >
> > If you have a subscription 'to', then you don't have PEP events,
> because
> > those are presence based (and you're not sending presence). But
> you can
> > use these to handle the item retrieval and maintain manual
> subscriptions.
> >
>
> And will increase traffic for clients which don't support
> microblogging.
> The PEP protocol is again loss. The things that it was designed for
> are
> work well only for very simple protocols like moods.
>
>
Right, and I agree this isn't a perfect solution, but I don't think
filtering at the destination server is a solution either, I went
through this already.
What about this - what if we had some mechanism for having your PEP
service subscribe to remote nodes, so that you in effect had a node
which aggregated remote nodes for you? Then the net result is one
that can be subscribed to using the normal filtering methods, and
you're more or less getting what you're asking for, but structured
such that it fits into the existing framework, and isn't forcing
constraints onto the entire system.
I'm aware that XEP-0253 exists, maybe there's something we could do
that's somewhat more transparent (ideally, I'm thinking the contact's
service needn't know anything about the chaining).
The client's view would - hopefully - end up being of a local PEP
node containing all their contact's microblogging posts.
> > I would note there are plenty of implementations that filter
> properly,
> > so I wouldn't say it's an impossible thing to do. Some of these
> run
> > quite big deployments.
>
> May I ask about examples of such software and deployments? I am
> worrying
> about high load too.
>
>
Operators of such services may be able to comment here.
> Also, I wanted to ask about big solutions which uses PEP/Pubsub in
> real
> life applications to learn how them work.
In my view, PEP is used quite heavily on the network as a whole.
I certainly see a large number of subscriptions across my server. I
have 97 contacts online currently, and 85 subscriptions, so a high
proportion of those contacts are using PEP-enabled clients. (We
internally generate a subscription at the root if there are any PEP
+filters, and one per extant node, so it's hard to translate this
into any percentage figures).
Sergey Dobrov
> On Fri Dec 16 09:41:11 2011, Sergey Dobrov wrote:
>> And will increase traffic for clients which don't support microblogging.
>> The PEP protocol is again loss. The things that it was designed for are
>> work well only for very simple protocols like moods.
>>
>>
> Right, and I agree this isn't a perfect solution, but I don't think
> filtering at the destination server is a solution either, I went through
> this already.
>
> What about this - what if we had some mechanism for having your PEP
> service subscribe to remote nodes, so that you in effect had a node
> which aggregated remote nodes for you? Then the net result is one that
> can be subscribed to using the normal filtering methods, and you're more
> or less getting what you're asking for, but structured such that it fits
> into the existing framework, and isn't forcing constraints onto the
> entire system.
We have the same disadvantages here:
1. node ACLs can't be used (but it can for filtering on destination server)
2. all node items should be stored on this aggregation service (but it
should not for filtering on destination server)
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.
Dave Cridland
> We have the same disadvantages here:
>
>
> 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.
Sergey Dobrov
> 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 same request can be done for the filtering on destination method.
>
>> 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.
Look, the main problem is to update clients because clients are more
widespread. Destination filtering will not break compatibility with
clients. But chains can broke it depends on implementation. But even for
server software we can maintain backwards-compatibility by using server
caps. The transition period can be used during it filtering on sender
can be announced as deprecated.
>
> 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.
Ok, you are suggest me to invent my own protocol. But it will be
reinvented PEP without the problems that we've found in the existent
standard. So we just will have two protocols which make the same thing.
Who will win in such case? I don't see where PEP is used in real life
applications except of not important data such as moods which nobody
will disturbed if them will not be delivered. I know that pubsub is used
in some proprietary decisions (I developed the one and I saw an adult
site based on pubsub recently), pubsub and not PEP! But you must keep in
mind that it's much more easier to develop proprietary solution because
it will be used only with your own code. If I will to write my own
proprietary microblogging I will just patch the server and will not care
but I want to make an open platform which anyone can integrate to.
That's the main disadvantage of the my competitor. If not that one then
what it will be? Proprietary has some advantages in the speed of write
code since they don't want to coordinate it with anyone. But I can't
solve such simple problem for more than half year. In such case XMPP
will not look good for developers. Who will use PEP if it has such
problems? We have XEP-277 and it is unsuitable for real life usage. Why
that happens? Because people who start to work with PEP are hope that
PEP is high quality standard which will be suitable for them
application, maybe relying on reputation of XSF and older specifications
them worked with. But if we will close the eyes on PEP's problems then
who will use it?
P.S. It will be really interesting if there are some examples of PEP
usage in commercial usage.
Dave Cridland
> Look, the main problem is to update clients because clients are more
> widespread. Destination filtering will not break compatibility with
> clients. But chains can broke it depends on implementation. But
> even for
> server software we can maintain backwards-compatibility by using
> server
> caps. The transition period can be used during it filtering on
> sender
> can be announced as deprecated.
>
>
We're talking about adding generic functionality in order to make
microblogging more useful. The only existing clients doing
microblogging over XMPP are the Buddycloud ones, which are using
generic pubsub.
You're arguing that, for example, PEP should fail to work unless both
servers support your new protocol. Given that the majority of XMPP
users do not have a server capable of any form of PEP, I don't see
why you think that your new, broken, PEP will deploy any better.
> > 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.
>
> Ok, you are suggest me to invent my own protocol.
No, I'm not. I'm saying that you can't use only the PEP subset, and
you need something more. That something could be a number of things,
including an entirely new protocol in the worst case, but I suspect
you need a lot less - a handful of existing XEP-0060 features would
work sufficiently well, and a few mionor extensions would probably
help for efficiency.
> P.S. It will be really interesting if there are some examples of PEP
> usage in commercial usage.
Buddycloud used to use PEP, very effectively. The reason they stopped
wasn't that PEP didn't work for them, it was because they wanted to
support users on Google, which has no PEP support. But Google users
can (and often do) see other people's PEP information; they just
can't publish their own.
What you're arguing for is a system where Google users wouldn't have
any PEP capability, and instead would get unfiltered subscriptions
whether they wanted it or not - particularly horrible for mobile
users. I don't think Google is going to suddenly implement your
protocol, so I think you need to figure out some other way to make
things work.
I've tried to help, but given you've decided you can't do anything
except rewrite PEP to suit your particular use-case, I'll leave you
to figure out the rest.
Sergey Dobrov
them is that them never will be implemented widely because of them
complexity.
ok, sorry for wasting your time, i am closing the project.
Tuomas Koski
On 22 December 2011 12:38, Sergey Dobrov <bin...@jrudevels.org> wrote:
> Buddycloud's standards are very far of generic pubsub. The problem with
> them is that them never will be implemented widely because of them
> complexity.
<as a "buddycloud dev">
Actually, while developing buddycloud, we have tried to keep it very
close to XEP-0060.
However application specific use cases and business logic makes these
things more complicated. If one wants to try to support easy to
understand privacy settings, moderation, other protocols as transport
layer, attachments and federation with other open platforms, things
get a bit more complicated than a simple "twitter kind of app".
After a quick thought, I think we have only added a new affiliation
state (moderator) on top of XEP. Rest of the app specific logic is
handled with "node as code" kind of logic: some predefined nodes are
created for a user when one registers with the component, etc.
<as a "buddycloud dev"/>
On 22 December 2011 12:38, Sergey Dobrov <bin...@jrudevels.org> wrote:
> ok, sorry for wasting your time, i am closing the project.
Never give up, never surrender! :-)
I would be happy if you would join us on buddycloud-dev mailing list
(https://groups.google.com/group/buddycloud-dev) or our conference
channel (see...@buddycloud.org) to discuss more about the problems
you are facing and the complexity of buddycloud. Fresh ideas and point
of views are always welcome.
Cheers,
--
Tuomas
Sergey Dobrov
> Hello all and specially Sergey,
>
> On 22 December 2011 12:38, Sergey Dobrov <bin...@jrudevels.org> wrote:
>> Buddycloud's standards are very far of generic pubsub. The problem with
>> them is that them never will be implemented widely because of them
>> complexity.
>
> <as a "buddycloud dev">
>
> Actually, while developing buddycloud, we have tried to keep it very
> close to XEP-0060.
>
> However application specific use cases and business logic makes these
> things more complicated. If one wants to try to support easy to
> understand privacy settings, moderation, other protocols as transport
> layer, attachments and federation with other open platforms, things
> get a bit more complicated than a simple "twitter kind of app".
>
> After a quick thought, I think we have only added a new affiliation
> state (moderator) on top of XEP. Rest of the app specific logic is
> handled with "node as code" kind of logic: some predefined nodes are
> created for a user when one registers with the component, etc.
>
> <as a "buddycloud dev"/>
I agree with you that XEP-60 doesn't cover all needed features. But I
think that it's better to make app just work without and then just
extend pubsub with more generic way. And another my point of view is
never copy twitter or any other web project since they have other
problems and specifics. I think that xmpp-based apps may be better and
more scalable but they don't need to copy web apps, they need to follow
them own way. I think that it turns out at me.
>
> On 22 December 2011 12:38, Sergey Dobrov <bin...@jrudevels.org> wrote:
>> ok, sorry for wasting your time, i am closing the project.
>
> Never give up, never surrender! :-)
I thinking now about forget about XSF and use patched module for my app.
Anyway, if I will do any other solution, it will be not standardized.
So, why to reinvent a bicycle if no pros found?
>
> I would be happy if you would join us on buddycloud-dev mailing list
> (https://groups.google.com/group/buddycloud-dev) or our conference
> channel (see...@buddycloud.org) to discuss more about the problems
> you are facing and the complexity of buddycloud. Fresh ideas and point
> of views are always welcome.
I will be glad to do that. I'll try to describe the architecture of my
app, if you are interested in it, so we can discuss it.
>
>
> Cheers,
> --
> Tuomas
Matthew Wild
> On 12/27/2011 01:12 AM, Tuomas Koski wrote:
>
>> On 22 December 2011 12:38, Sergey Dobrov <bin...@jrudevels.org> wrote:
>>> ok, sorry for wasting your time, i am closing the project.
>>
>> Never give up, never surrender! :-)
>
> I thinking now about forget about XSF and use patched module for my app.
> Anyway, if I will do any other solution, it will be not standardized.
> So, why to reinvent a bicycle if no pros found?
>
Completely "forgetting" the XSF wouldn't be wise or constructive, in
my opinion. The XSF:
1) Does not claim to have published a protocol for every possible application
2) Does not force you to use only its published protocols
3) Is a community of people, and one open to contributions
Therefore, if you really believe there is a space for a "different
PEP" then you are welcome to implement it, and submit your protocol as
a XEP. As long as it's basically sane it'll be accepted and published
as an experimental XEP. Useful links:
- http://xmpp.org/extensions/xep-0143.html
- http://xmpp.org/extensions/xep-0001.html
Regards,
Matthew
Sergey Dobrov
> On 28 December 2011 10:33, Sergey Dobrov <bin...@jrudevels.org> wrote:
>> On 12/27/2011 01:12 AM, Tuomas Koski wrote:
>>
>
>>> On 22 December 2011 12:38, Sergey Dobrov <bin...@jrudevels.org> wrote:
>>>> ok, sorry for wasting your time, i am closing the project.
>>>
>>> Never give up, never surrender! :-)
>>
>> I thinking now about forget about XSF and use patched module for my app.
>> Anyway, if I will do any other solution, it will be not standardized.
>> So, why to reinvent a bicycle if no pros found?
>>
>
> Completely "forgetting" the XSF wouldn't be wise or constructive, in
> my opinion. The XSF:
I don't want to forget it completely. I wish to continue to contribute
in XEP-277. But I must to implement good integration with presences if I
want to force this work. I just can't fork PEP, it's too complex thing
for one person, so the only way is to create nasty hack which will be
backwards compatible with XSF's standards. Please, fix me if my
reasoning is wrong.
>
> 1) Does not claim to have published a protocol for every possible application
Sure. But it have XEP-277 and it's hard to use it in real life.
Moreover, my problem is fundamental problem which can disturb to
implement application level protocols based on PEP. How to solve it if
not with XSF?
> 2) Does not force you to use only its published protocols
Correct. I can republish XEP-277 if it will not be good for me. But I
can't republish pubsub/PEP, it's too low level to have much versions of
them.
> 3) Is a community of people, and one open to contributions
>
> Therefore, if you really believe there is a space for a "different
> PEP" then you are welcome to implement it, and submit your protocol as
> a XEP. As long as it's basically sane it'll be accepted and published
> as an experimental XEP. Useful links:
>
> - http://xmpp.org/extensions/xep-0143.html
> - http://xmpp.org/extensions/xep-0001.html
>
I understand that. But I think that this is very bad solution to have
two versions of the same protocol with the only difference in improved
message filtering. Such things brake implementation of features in
clients and servers.
> Regards,
> Matthew