Hi,
On Feb 12, 2013, at 10:13 AM, Sergey Dobrov <bin...@jrudevels.org> wrote: > 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. yes scaling and performance issues in 2.x is quite known… And I don't even think that Ejabberd 3.0 will be open sourced. You should take a look at mongooseIM, that is an erlang solutions open source fork. > >> - 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.
