phurple - libpurple bindings for PHP

[Anatol Belski]

On Thu, January 9, 2014 22:46, Peter Lawler wrote:
> On 10/01/14 06:58, Anatol Belski wrote:
>
>>> Yes, there are recipients on this list who know how to do it but
>>> they're probably still under NDA so I doubt we'll ever hear too much
>>> from them on this topic
>>>
>> The way to do that is more or less obvious. The question is more about
>> man hours, feasibility and willingness. As the patch would be gigantic.
>> Plus,
>> all the external plugins have to be eventually adapted.
>
> A-yup.
>
>
> I don't mean any offence to the devs or CPW's, but generally speaking
> there's probably about half a dozen people who are frequently active on
> libpurple (the rest I'd say are infrequent, or retired but prompt for
> patches when/where needed). They do it in their free time, so they tend to
> hack on what they want for themselves.
>
> Given the size the patchset would be, I can't foresee it happening
> without major sponsorship of a couple of devs full time or a corporate
> doing it and (properly) handing the code upstream.
>
Neither meant I any offense, just the status quo. Myself I'm actually one
of that kind of hacking folks, too :)

> Now the conspiracy theorists may suggest that Meebo et all just didn't
> hand code upstream. I'm more of the mind they probably used some middleware
> to (a) provide a form of thread safety (b) make it easier to keep possible
> damage from API changes between FE & BE down by not necessarily having to
> change both FE or BE code and suffer unexpected changes elsewhere in their
> system. Dunno what the kids do these days, but back when I was an engineer
> the coders used CORBA (yeah yeah yeah, I'm old!) type stuff to provide
> this sort of glue.
Well, I'm even not sure that was libpurple only one they've used. Things
like jabber transports, so some jabberd, look promising enough for basing
a backend on them. Maybe there was just a partial usage for some
protocols. Anyway just speculations :)

> Which kind of brings to mind. What would be actually be 'better' for
> PHP? libpurple bindings, or generic IM type API to which libpurple and
> other backends could utilise.
>
One user per process and no thread safety is definitely something not
nice. The TS thing is, as i've mentioned the possibility to work with some
thread based SAPI. But one user per process means even in NTS mode it's
impossible to properly incapsulate libpurple into an object. In PHP
there's a singleton instance per process. Well, good enough, the old good
UNIX style. Turning back to a possible backend model for Meebo, that would
work the same way Apache prefork does - run root daemon, loop(listen,
accept connection, fork child). Still, there is a lot of stuff works
successfully that way and will do for long. But still, we live in 2014,
not in 1960 :)

Regards

Anatol