This is really a question for Collabora :) Ccing them...
On Thu, Dec 11, 2008 at 2:49 PM, Martin Langhoff <[EMAIL PROTECTED]> wrote: > On Thu, Dec 11, 2008 at 9:43 AM, Marco Pesenti Gritti > <[EMAIL PROTECTED]> wrote: >> Just fyi, I submitted a gadget fedora package for review. It's going >> to require ejabberd 2.0.2. >> >> https://bugzilla.redhat.com/show_bug.cgi?id=475971 > > When you have a bit of time, I am still keen on understanding how does > Gadget fit in the wider picture. > > With the "OMG! ejabberd's memory and roster mgmt are Out Of Control" > thing mostly behind us, I want to have a clear picture of why and how > Gadget fits into the picture. And at what (cpu, memory) cost, > specially for the 3K users scenarios we're looking at. > > In other words, we are finding that ejabberd is very amenable to > having its behaviour changed in interesting ways with > > - minimalistic Erlang plugins > - poking at its internal mnesia DB via the xml-rpc plugin > - using an external DB instead of Mnesia, and having external > programs manipulate the DB > > all of these things keep us on using standard XMPP (so our client and > server are more generic, and interchangeable) and from a scalability > POV avoid adding additional processes (except for the DB). > > OTOH, I'm not against Gadget. It's just that it's a big unknown to me > at a stage where -- without that much effort -- we seem to be getting > ejabberd under control and playing nice. > > cheers, > > > > m > -- > [EMAIL PROTECTED] > [EMAIL PROTECTED] -- School Server Architect > - ask interesting questions - don't get distracted with shiny stuff > - working code first > - http://wiki.laptop.org/go/User:Martinlanghoff > _______________________________________________ Server-devel mailing list [EMAIL PROTECTED] http://lists.laptop.org/listinfo/server-devel