Comment on PEP / versus pure pubsub usage

[Mickaël Rémond]

Hello,

I see that the packet used by the client use some implicits offered by
PEP.
However, PEP has the drawback that it is tight to the user, which
makes difficult to do quite a few things.

First, semantically the jid of the owner is implied to get access to
the reply node name. Even if implicit the jid is part of the node ID.
Second, what about persistance of conversation and replies when you
delete a user.

In that situation, I really think that the system should not rely on
PEP nodes but on standard full XMPP pubsub nodes.

Any comment or reason the PEP semantic is user in client ?

--
Mickaël Rémond
http://www.process-one.net

[Laurent Eschenauer]

> Any comment or reason the PEP semantic is user in client ?

Let me jump in :-) A lot of the early design choices where driven by
'building it quickly' and 'ease to do in java on openfire (which is
buggy and does not follow all xmpp specs). So they may not ideal and
should be refactored. I cannot comment on the commenting flow however,
it was factored in after I left.

Now, at the xmpp summit, we kinda of reached consensus on the fact
that this thing should become a component to increase adoption and
that decoupling from pep would make sense. The buddycloud people have
a "channel" spec in that spirit:
http://open.buddycloud.com/channel-protocol

I suggest that you have a chat with Simon if you see him tomorrow.

Cheers,

Laurent

[João M. Gonçalves]

Hello all,
I'm a PhD student and researcher and I'm trying out 1SW as an option
for basing a privacy-related proof of concept.
I'm quite excited so far, but this PEP vs PubSub vs buddycloud
channels problem seems to be the project's biggest (architectural)
issue... is there a likely direction where this will evolve? What is
the problem with pure XMPP PubSub? The feature "filter and selective
subscriptions" on the roadmap is to be built on top of PEP?
Regards,
João

[Tuomas Koski]

Hi,

2011/2/6 Mickaël Rémond <mre...@gmail.com>:

> Hello,
>
> I see that the packet used by the client use some implicits offered by
> PEP.
> However, PEP has the drawback that it is tight to the user, which
> makes difficult to do quite a few things.
>
> First, semantically the jid of the owner is implied to get access to
> the reply node name. Even if implicit the jid is part of the node ID.
> Second, what about persistance of conversation and replies when you
> delete a user.
>
> In that situation, I really think that the system should not rely on
> PEP nodes but on standard full XMPP pubsub nodes.

yes, the same problems were noticed in the buddycloud project so we
switched to full pubsub version.

Cheers,
--
Tuomas

[Tuomas Koski]

Hi,

2011/2/11 João M. Gonçalves <jmg...@gmail.com>:

> Hello all,
> I'm a PhD student and researcher and I'm trying out 1SW as an option
> for basing a privacy-related proof of concept.
> I'm quite excited so far, but this PEP vs PubSub vs buddycloud
> channels problem seems to be the project's biggest (architectural)
> issue... is there a likely direction where this will evolve? What is
> the problem with pure XMPP PubSub? The feature "filter and selective
> subscriptions" on the roadmap is to be built on top of PEP?

"buddycloud channels" is technically a pure PubSub solution. It only
has some extra features to make client programs a little faster to
develop and mainly to reduce some traffic (important for mobile apps).

Cheers,
--
Tuomas