Hi,
On Mar 28, 2008, at 7:06 PM, Tro wrote:
On Thursday 27 March 2008, Pedro Melo wrote:
On Mar 26, 2008, at 1:29 PM, David Janes wrote:
On Wed, Mar 26, 2008 at 8:19 AM, Kevin Smith <[EMAIL PROTECTED]>
wrote:
On Wed, Mar 26, 2008 at 12:50 PM, Greg Wilson
<[EMAIL PROTECTED]> wrote:
There's been a fair bit of discussion in the last couple of
days on the Python SoC mailing list about how useful it would
be to have an XMPP server in Python
Why would having one written in Python in particular be useful to
you?
/K
1) because many of us work in Python environments and would like to
continue to do so
2) because Python kicks ass and thus there are many Python
programmers
and thus once we get the framework in place is likely to be used and
extended
3) because this is a noticeable deficiency in Python's otherwise
excellent support of Internet protocols
May I suggest that instead of a full server, you implement a XMPP
router instead?
The difference for me is that a XMPP router does not have a session
manager. It only has:
* S2S: for federation;
* XEP-0114 and XEP-0225 support.
This would allow anyone to write a component in any language they
want, and the make it available in the XMPP network without having to
run a full server.
This is something that I think does not exist, and that many people
could use.
We're already writing a full server (it's a course project right
now), so I
think it's too late to turn it into a router. However, I really
like your
idea. After the hand-off, if I have time, I'll try to get some work
done in
that area.
It is never too late to limit the scope of a project :).
But you can separate the two: a router, and the SM that sits on top.
As long as I can ditch your SM and just use the router, I'm happy.
And if you have two persons working on this, make one of them write
the router, and the other, the SM dude, is a client of the router
using XEP-0225.
Regarding the SM, all of them usually have the same settings, to
define where the data (user, roster, private storage, vcards, PEP,
etc) is stored. Let me leave you my suggestions:
* try and have a single back-end, web-services powered: this would
allow existing social sites to plug your server into their HTTP
infrastructure, and it would be a key difference between your server
and all the others;
* PEP is the most important server-side service to have from the
start;
* implement the vcard and private storage on top of PEP: it should
be trivial, and you get notifications of vcard updates and private
storage updates for free (yes, yes, they are not standard but they
don't break anything and only people who put (for ex) vcard-temp
+notify in their disco#info reply will get them.
Best regards and good luck,
--
HIId: Pedro Melo
SMTP: [EMAIL PROTECTED]
XMPP: [EMAIL PROTECTED]
