On 02/12/2013 02:34 PM, Simon Tennant wrote: > I understand that you want to do lookup in PEP. I'd be very wary of > depending on it to build a full scaled social platform. > > We tried using PEP to build buddycloud. We created a bunch of nodes for > each and would push out updates based on presence. This kinda worked > with the following caveats:: > - it was server specific (any changes to PEP had to be made to each > server)/you loose the portability of XMPP components If the features will be described in XEPs any server will be able to implement them. But they are needed to be interested in it. The interest may be cause with interesting and powerful user applicable protocols like XEP-277. But we are really need to make XEP-60 and PEP more usable for this kind of things.
Also, I already told that we need a standard that will allow services like PEP to be external like XEP-114 allows gateways to be external. I still thing this is the most priority task for pubsub development. > - scaling and performance (this could have been an issue with ejabberd > at the time). Yeah, this is an ejabberd issue they are hoping to fix in 3.0. Unfortunately, we are waiting for 3.0 too long. > - difficult to build any extra business logic into PEP. For > example:"this set of users can reply to my posts" I don't see the problem here technically. This is impossible with current standards but technically it's not a problem at all. > > I think that the OneSocialWeb guys ran into similar issues with their > PEP-based service. > > Our XMPP architecture for buddycloud has shifted: build as much as > possible outside of the XMPP server core. We use components to scale out > services and use the XMPP server just as a router (the famous "xmpp > middleware" topic). The benefit of using components for your service is > that running Movim will have the ability to switch out their XMPP server > as their needs change. > > One solution that might give you some milage: using DISCO to point to a > pub sub component that is nominated for social activities? (Something > like https://buddycloud.org/wiki/XMPP_XEP#buddycloud_Server_Discovery). > This will give you much more flexibility in the future and nto tie your > solution to a particular XMPP server vendor. > > S. -- With best regards, Sergey Dobrov, XMPP Developer and JRuDevels.org founder.
