Re: [jdev] My GSoC project : to continue the PyMSNt development.
On Thu, Apr 10, 2008 at 12:54 AM, Sander Devrieze [EMAIL PROTECTED] wrote: This is not bad. For the Aunt Tilly user using the XMPP client it should just work. Agreed, this is better for the Aunt Tilly scenario, but far worse for the early XMPP adopter that can't receive files from his MSN tech friends, causing them to think XMPP can't do FT. -- - Norman Rasmussen - Email: [EMAIL PROTECTED] - Home page: http://norman.rasmussen.co.za/
Re: [jdev] My GSoC project : to continue the PyMSNt development.
2008/4/10, Richard Dobson [EMAIL PROTECTED]: Norman Rasmussen wrote: On Thu, Apr 10, 2008 at 12:54 AM, Sander Devrieze [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: This is not bad. For the Aunt Tilly user using the XMPP client it should just work. Agreed, this is better for the Aunt Tilly scenario, but far worse for the early XMPP adopter that can't receive files from his MSN tech friends, causing them to think XMPP can't do FT. Yes definitely it should really work both ways or not at all IMO, its not all that hard to implement this and there are several ways you can do it, and if you have already implemented the transfer of avatars or custom emoticons in the msn protocol then you are most of the way to implementing msn filetransfer anyway. Then once you can send and receive files to the msn contacts on the msn protocol side its just a matter of implementing your chosen XMPP file transfer method on the XMPP side of the transport, be that SI/IBB/Bytestreams or just the passing of the URL that the XMPP client can download the file from via HTTP, personally id go for implementing SI and the jingle based method once that's finalised as the experience for the XMPP user will then be far more seemless. Who said targeting tech people is a good idea? Did tech people were the ones that choose which closed IM system they use? Compare targeting tech people with Mozilla or Linux distributions before Ubuntu appeared and targeting Aunt Tillies with Firefox, Ubuntu-like distributions or Eee PC with Linux on it. Which strategy is the most successful in all these examples: targeting tech people or targeting Aunt Tillies? Conclusion: tech people (WE!) do NOT matter when network effects are involved, Aunt Tillies are numerous and thus do matter. -- Mvg, Sander Devrieze.
Re: [jdev] My GSoC project : to continue the PyMSNt development.
2008/4/10, Richard Dobson [EMAIL PROTECTED]: Who said targeting tech people is a good idea? Did tech people were the ones that choose which closed IM system they use? Compare targeting tech people with Mozilla or Linux distributions before Ubuntu appeared and targeting Aunt Tillies with Firefox, Ubuntu-like distributions or Eee PC with Linux on it. Which strategy is the most successful in all these examples: targeting tech people or targeting Aunt Tillies? Conclusion: tech people (WE!) do NOT matter when network effects are involved, Aunt Tillies are numerous and thus do matter. Why put up artificial barriers? What's wrong with things like filetransfer working both ways? If you have already implemented sending files to msn users then its trivial to implement receiving of files too. Doing half of a job only serves to make XMPP look bad in peoples eyes. I was talking about webdav file transfers which will not need reverse engineering of the closed network file transfer protocol as the transport can simply send the webdav uri as a plain text message to the contact on the closed IM system. This file transfer method will be safe for protocol changes on the closed network and thus will *always* work once it is stable. This file transfer method also will need less resources from the XMPP server on which the transport is hosted (when the webdav server is not on the same server). So, this file transfer method will be more scalable than other file transfer methods that will need to go through the transport, be converted, etc. -- Mvg, Sander Devrieze.
Re: [jdev] My GSoC project : to continue the PyMSNt development.
Norman Rasmussen wrote: On Thu, Apr 10, 2008 at 12:54 AM, Sander Devrieze [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: This is not bad. For the Aunt Tilly user using the XMPP client it should just work. Agreed, this is better for the Aunt Tilly scenario, but far worse for the early XMPP adopter that can't receive files from his MSN tech friends, causing them to think XMPP can't do FT. Yes definitely it should really work both ways or not at all IMO, its not all that hard to implement this and there are several ways you can do it, and if you have already implemented the transfer of avatars or custom emoticons in the msn protocol then you are most of the way to implementing msn filetransfer anyway. Then once you can send and receive files to the msn contacts on the msn protocol side its just a matter of implementing your chosen XMPP file transfer method on the XMPP side of the transport, be that SI/IBB/Bytestreams or just the passing of the URL that the XMPP client can download the file from via HTTP, personally id go for implementing SI and the jingle based method once that's finalised as the experience for the XMPP user will then be far more seemless. Richard
Re: [jdev] My GSoC project : to continue the PyMSNt development.
I was talking about webdav file transfers which will not need reverse engineering of the closed network file transfer protocol as the transport can simply send the webdav uri as a plain text message to the contact on the closed IM system. This file transfer method will be safe for protocol changes on the closed network and thus will *always* work once it is stable. This file transfer method also will need less resources from the XMPP server on which the transport is hosted (when the webdav server is not on the same server). So, this file transfer method will be more scalable than other file transfer methods that will need to go through the transport, be converted, etc. I see well I wouldnt really consider that as proper file transfer, its more just sending a link to someone, also just had a look at the documentation for pyMSNt and that says it already supports MSN filetransfers using SI (XEP-0096,XEP-0065) so this argument is pretty much moot as its already been implemented in one of the more widely used MSN transports, also it really is not that difficult to implement and the reverse engineered protocol docs are out there, the protocol for filetransfers on msn also doesn't change (at all AFAIK) for a particular version of the MSN protocol (microsoft versions their protocol with official clients and servers supporting several versions, when you connect you tell the server which version you wish to use), I would suggest you read up on the MSN protocol to better understand things. So in conclusion its already been implemented (so not the issue you are trying to make it out to be), there is no need to worry about the msn protocol side suddenly changing as it simply won't unless the transport is upgraded to support a newer version of the protocol in which case the developer will know that they will need to make modifications to the protocol handling. Richard
Re: [jdev] My GSoC project : to continue the PyMSNt development.
It was an *example*... 2008/4/10, Richard Dobson [EMAIL PROTECTED]: I was talking about webdav file transfers which will not need reverse engineering of the closed network file transfer protocol as the transport can simply send the webdav uri as a plain text message to the contact on the closed IM system. This file transfer method will be safe for protocol changes on the closed network and thus will *always* work once it is stable. This file transfer method also will need less resources from the XMPP server on which the transport is hosted (when the webdav server is not on the same server). So, this file transfer method will be more scalable than other file transfer methods that will need to go through the transport, be converted, etc. I see well I wouldnt really consider that as proper file transfer, its more just sending a link to someone, also just had a look at the documentation for pyMSNt and that says it already supports MSN filetransfers using SI (XEP-0096,XEP-0065) so this argument is pretty much moot as its already been implemented in one of the more widely used MSN transports, also it really is not that difficult to implement and the reverse engineered protocol docs are out there, the protocol for filetransfers on msn also doesn't change (at all AFAIK) for a particular version of the MSN protocol (microsoft versions their protocol with official clients and servers supporting several versions, when you connect you tell the server which version you wish to use), I would suggest you read up on the MSN protocol to better understand things. So in conclusion its already been implemented (so not the issue you are trying to make it out to be), there is no need to worry about the msn protocol side suddenly changing as it simply won't unless the transport is upgraded to support a newer version of the protocol in which case the developer will know that they will need to make modifications to the protocol handling. Richard -- Mvg, Sander Devrieze.
Re: [jdev] My GSoC project : to continue the PyMSNt development.
2008/4/9, Peter Saint-Andre [EMAIL PROTECTED]: Daniel Henninger wrote: I don't disagree from the client perspective. But my philosophy has always been to make XMPP as great as it can be, then everyone else will eventually decide that they need to use XMPP and not some proprietary garbage. I won't get into my diatribe about why I think that will never happen. Aside from saying why are people still using IE6 and even IE5? ;) I've always been a big proponent of let them use what they want, we'll do what we can do make the world able to communicate better. That doesn't mean trying to tell someone your client blows, use this instead. Personally I see no problem with transport work as part of the GSoC. HOWEVER I do agree that, to me, the greater spirit of the XMPP involvement would be to learn more about XMPP and improve upon it directly. Can that be done by improving upon existing transports? Maybe. In an ideal world, it could be awefully nice to see a project in which some sort of XEP gets implemented and improved upon, or some sort of new XEP concept gets written. Really I have nothing against transports. However, my focus is on making native XMPP technologies as powerful as possible. Personally I'd rather support some fun project like MSN-like emoticons over XMPP than just bridge to a closed technology. But that's just my opinion. :) When you have a larger user base, you get these fun things automatically: end users will pull for these features instead of some instance pushing them. -- Mvg, Sander Devrieze.
Re: [jdev] My GSoC project : to continue the PyMSNt development.
One of the things that makes my life easier /is/ the gateways. I work at a pro M$ company so they are Live Messenger through and through: despite my VERY BEST efforts to convert the entire company. Being able to use MSN via Jabber has been a huge help for me, but sometimes I have to log into MSN because of the missing functionality (we really do use the complete MSN feature set). Some people just can't convert completely. My ZIM$0.01 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sander Devrieze Sent: 09 April 2008 01:15 PM To: Jabber/XMPP software development list Subject: Re: [jdev] My GSoC project : to continue the PyMSNt development. 2008/4/9, Peter Saint-Andre [EMAIL PROTECTED]: Daniel Henninger wrote: I don't disagree from the client perspective. But my philosophy has always been to make XMPP as great as it can be, then everyone else will eventually decide that they need to use XMPP and not some proprietary garbage. I won't get into my diatribe about why I think that will never happen. Aside from saying why are people still using IE6 and even IE5? ;) I've always been a big proponent of let them use what they want, we'll do what we can do make the world able to communicate better. That doesn't mean trying to tell someone your client blows, use this instead. Personally I see no problem with transport work as part of the GSoC. HOWEVER I do agree that, to me, the greater spirit of the XMPP involvement would be to learn more about XMPP and improve upon it directly. Can that be done by improving upon existing transports? Maybe. In an ideal world, it could be awefully nice to see a project in which some sort of XEP gets implemented and improved upon, or some sort of new XEP concept gets written. Really I have nothing against transports. However, my focus is on making native XMPP technologies as powerful as possible. Personally I'd rather support some fun project like MSN-like emoticons over XMPP than just bridge to a closed technology. But that's just my opinion. :) When you have a larger user base, you get these fun things automatically: end users will pull for these features instead of some instance pushing them. -- Mvg, Sander Devrieze.
Re: [jdev] My GSoC project : to continue the PyMSNt development.
Jonathan Dickinson wrote: One of the things that makes my life easier /is/ the gateways. I work at a pro M$ company so they are Live Messenger through and through: despite my VERY BEST efforts to convert the entire company. Being able to use MSN via Jabber has been a huge help for me, but sometimes I have to log into MSN because of the missing functionality (we really do use the complete MSN feature set). Some people just can't convert completely. Understood. But what features do most people really use? Is it just presence and IM (and possibly groupchat), or do most people also require the ability for file transfers, voice calls, emoticons (etc.) to go across the bridge between Jabber and MSN? And perhaps those who really do need the complete feature set could step up to the plate and help fund work on the transports? Not everything needs to happen through the XSF or the Google Summer of Code. TANSTAAFL. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [jdev] My GSoC project : to continue the PyMSNt development.
TANSTAAFL = Taking Another Step Toward An Awesome Full Life? On Wed, Apr 9, 2008 at 10:25 AM, Peter Saint-Andre [EMAIL PROTECTED] wrote: Jonathan Dickinson wrote: One of the things that makes my life easier /is/ the gateways. I work at a pro M$ company so they are Live Messenger through and through: despite my VERY BEST efforts to convert the entire company. Being able to use MSN via Jabber has been a huge help for me, but sometimes I have to log into MSN because of the missing functionality (we really do use the complete MSN feature set). Some people just can't convert completely. Understood. But what features do most people really use? Is it just presence and IM (and possibly groupchat), or do most people also require the ability for file transfers, voice calls, emoticons (etc.) to go across the bridge between Jabber and MSN? And perhaps those who really do need the complete feature set could step up to the plate and help fund work on the transports? Not everything needs to happen through the XSF or the Google Summer of Code. TANSTAAFL. Peter -- Peter Saint-Andre https://stpeter.im/
Re: [jdev] My GSoC project : to continue the PyMSNt development.
On Wed, Apr 9, 2008 at 4:25 PM, Peter Saint-Andre [EMAIL PROTECTED] wrote: Understood. But what features do most people really use? Is it just presence and IM (and possibly groupchat), or do most people also require the ability for file transfers, voice calls, emoticons (etc.) to go across the bridge between Jabber and MSN? - IM and presense are critical - Groupchat is pretty important in a business environment - FT is important for sending a quick picture (or screenshot of a bug/crash) - Voice calls are a nice to have, but we don't have a stable+implemented XEP yet - Emoticons would be a real croud pleaser, but they're 100% eye candy And perhaps those who really do need the complete feature set could step up to the plate and help fund work on the transports? Not everything needs to happen through the XSF or the Google Summer of Code. Agreed, at the moment the various transports only have maintainers (not new-feature-implementers). I think all of us find that we'd love to spend time on them, but due to other commitments (including those that end up earning us cold-hard-cash), we just haven't had time or motivation to donate to the transports. If people want to see new features, then start collecting up some cash - if you can get enough together, then there's bound to be a developer out there that will bite. (This worked for the python MySpaceIM transport -- to be released as GPL in about July) -- - Norman Rasmussen - Email: [EMAIL PROTECTED] - Home page: http://norman.rasmussen.co.za/
Re: [jdev] My GSoC project : to continue the PyMSNt development.
On Wed, Apr 9, 2008 at 7:10 PM, Sander Devrieze [EMAIL PROTECTED] wrote: 4) When closed network contacts try to send you a file they can get an unfriendly technical error message like Your client does not support webdav file transfers. Contact owner of the network for more information. This is bad. If anything it's _more_ important to make it work the other way around, so that if someone sends you a file you can receive it, but if they ask you to send them a file, you can do it via email. Actually, any error message is bad - it should 'just-work' -- - Norman Rasmussen - Email: [EMAIL PROTECTED] - Home page: http://norman.rasmussen.co.za/
Re: [jdev] My GSoC project : to continue the PyMSNt development.
2008/4/9, Norman Rasmussen [EMAIL PROTECTED]: On Wed, Apr 9, 2008 at 7:10 PM, Sander Devrieze [EMAIL PROTECTED] wrote: 4) When closed network contacts try to send you a file they can get an unfriendly technical error message like Your client does not support webdav file transfers. Contact owner of the network for more information. This is bad. If anything it's _more_ important to make it work the other way around, so that if someone sends you a file you can receive it, but if they ask you to send them a file, you can do it via email. Actually, any error message is bad - it should 'just-work' This is not bad. For the Aunt Tilly user using the XMPP client it should just work. If Aunt Tilly can do everything with all her contacts whether or not they are on a closed network, the XMPP client will be Ok. If she can't send a file, the client will suck. The other way around is not that important: when the Aunt Tilly user using the closed network client can't send a file to a contact behind a transport, this is no problem at all for the XMPP community. This Aunt Tilly will think the closed network client she is using sucks (e.g. MSN Messenger) and she may start looking for something more reliable when this happens often. Of course this will happen more often when more of her contacts start using an XMPP client and a transport (network effects as judo strategy). Example discussion between 2 Aunt Tilly users. Tilly1 uses Coccinella to connect to MSN. Tilly1 does not know Coccinella is called an XMPP or Jabber client. Tilly1 only knows it's a tool with which she can chat with Tilly2. Tilly2 is using Windows Live Messenger, the official client of the closed MSN network. Tilly2 also does not know anything about computers. Tilly2 tries to send a file to Tilly1. The transport between the Tillies sends an unfriendly, geekly error message back to Tilly2 that she for sure will not understand. Tilly2 chats to Tilly1 that she tried to send a file and that it did not worked. Tilly1 replies that she never had problems with sending files with her chat tool. Tilly1 says she will try to send a file to Tilly2 to test. The file transfer works! Hence, Tilly2 gets interested in the chat tool of Tilly1 and asks Tilly1 how it's called and where she can get it. Tilly2 switches to Coccinella and also will start using the MSN transport. Now there is 1 additional user which will increase the number of similar issues (also see http://en.wikipedia.org/wiki/Metcalfe's_law ). More and more people on the MSN network using the official Windows Live Messenger client will get reliability issues with file transfers. In this way, thanks to the MSN transport and people using it, Windows Live Messenger gets a reputation of being unreliable. In contrast, more and more people who switched to an XMPP client without knowing they are using an XMPP client will be happy about their new IM software as it never has trouble with file transfers. XMPP clients will get a better reputation and word of mouth recommendations will do the rest. -- Mvg, Sander Devrieze.
Re: [jdev] My GSoC project : to continue the PyMSNt development.
Florent wrote: Hi all, I have seen this week only that James Bunton no longer wanted to continue developing the MSN transport, since all his friends are now using Jabber. Perhaps that's a sign of the times. :) I'm also applying for two other GSoC projects, but this one is the most motivating for me. Personally, I have not used any of the transports in many years. While I understand that many Jabber users still like and use transports to the legacy IM services, I am not convinced that working on transports is an appropriate topic for the Google Summer of Code. I plan to give my votes to projects that improve or extend XMPP itself, not provide bridges to closed technologies. My $0.02. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [jdev] My GSoC project : to continue the PyMSNt development.
2008/4/8, Peter Saint-Andre [EMAIL PROTECTED]: I am not convinced that working on transports is an appropriate topic for the Google Summer of Code. I plan to give my votes to projects that improve or extend XMPP itself, not provide bridges to closed technologies. I do not agree on this. Good transports are advantageous for XMPP. As I already wrote on http://coccinella.im/whytransportsmatter -- More and better transports are needed to allow XMPP clients to compete effectively with the key feature of multiprotocol clients: interoperability with multiple closed networks. Multiprotocol clients can't innovate as fast as XMPP clients can (see above), so we can tackle them on the interoperability feature which is XMPP's core feature. Every user that uses a transport instead of the official client to access the closed network or instead of a multiprotocol client *contributes* to XMPP in these ways: * Network effects: even if this user only uses the XMPP client to communicate with people on closed networks he *needs* an XMPP account on a server. There are even transports that can detect if one of your contacts on a closed network is also using a transport so that you can add his XMPP ID instead! * Testing: every additional user may find bugs in the XMPP client or the XMPP server. Fixing these bugs will help the broader XMPP community. * Reducing client choice and user experience on closed networks: a stronger focus of the XMPP community on transports will reduce client choice and user experience on closed networks. This will increase the value of XMPP for users. See my article for more information on this one or ask me if you don't understand this. * Attracting more developers to the XMPP community: a user using an XMPP client, an XMPP account on an XMPP server, and a transport may attract people to contribute to all of these. If this user would have used a multiprotocol client, this will only attract people to contribute to the closed protocol plugin of this multiprotocol client and the user interface of this client. Such contributions will benefit the XMPP community close to zero: only contributions to the user interface may be beneficial also this also may be seen as a disadvantage (e.g. ugly XMPP-specific dialogs in Adium). -- Mvg, Sander Devrieze.
Re: [jdev] My GSoC project : to continue the PyMSNt development.
Sander Devrieze wrote: 2008/4/8, Peter Saint-Andre [EMAIL PROTECTED]: I am not convinced that working on transports is an appropriate topic for the Google Summer of Code. I plan to give my votes to projects that improve or extend XMPP itself, not provide bridges to closed technologies. I do not agree on this. Yeah, but you don't have a vote. :P Good transports are advantageous for XMPP. As I already wrote on http://coccinella.im/whytransportsmatter -- More and better transports are needed to allow XMPP clients to compete effectively with the key feature of multiprotocol clients: interoperability with multiple closed networks. Multiprotocol clients can't innovate as fast as XMPP clients can (see above), so we can tackle them on the interoperability feature which is XMPP's core feature. I don't disagree from the client perspective. But my philosophy has always been to make XMPP as great as it can be, then everyone else will eventually decide that they need to use XMPP and not some proprietary garbage. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [jdev] My GSoC project : to continue the PyMSNt development.
I don't disagree from the client perspective. But my philosophy has always been to make XMPP as great as it can be, then everyone else will eventually decide that they need to use XMPP and not some proprietary garbage. I won't get into my diatribe about why I think that will never happen. Aside from saying why are people still using IE6 and even IE5? ;) I've always been a big proponent of let them use what they want, we'll do what we can do make the world able to communicate better. That doesn't mean trying to tell someone your client blows, use this instead. Personally I see no problem with transport work as part of the GSoC. HOWEVER I do agree that, to me, the greater spirit of the XMPP involvement would be to learn more about XMPP and improve upon it directly. Can that be done by improving upon existing transports? Maybe. In an ideal world, it could be awefully nice to see a project in which some sort of XEP gets implemented and improved upon, or some sort of new XEP concept gets written. Either way, the PyMSNt project idea could always be suggested over in the Python GSoC stuff as well. Daniel On 4/8/08 1:40 PM, Peter Saint-Andre [EMAIL PROTECTED] wrote: Sander Devrieze wrote: 2008/4/8, Peter Saint-Andre [EMAIL PROTECTED]: I am not convinced that working on transports is an appropriate topic for the Google Summer of Code. I plan to give my votes to projects that improve or extend XMPP itself, not provide bridges to closed technologies. I do not agree on this. Yeah, but you don't have a vote. :P Good transports are advantageous for XMPP. As I already wrote on http://coccinella.im/whytransportsmatter -- More and better transports are needed to allow XMPP clients to compete effectively with the key feature of multiprotocol clients: interoperability with multiple closed networks. Multiprotocol clients can't innovate as fast as XMPP clients can (see above), so we can tackle them on the interoperability feature which is XMPP's core feature. Peter
Re: [jdev] My GSoC project : to continue the PyMSNt development.
Dnia 2008-04-08, wto o godzinie 18:08 +, Daniel Henninger pisze: I won't get into my diatribe about why I think that will never happen. People were saying the same about SMTP. You know - this marginal protocol used to bridge proprietary Electronic Mail systems... -- /\_./o__ Tomasz Sterna (/^/(_^^' http://www.xiaoka.com/ ._.(_.)_ im:[EMAIL PROTECTED]
Re: [jdev] My GSoC project : to continue the PyMSNt development.
Ok, I’ll believe it when I see it. Daniel On 4/8/08 5:48 PM, Tomasz Sterna [EMAIL PROTECTED] wrote: Dnia 2008-04-08, wto o godzinie 18:08 +, Daniel Henninger pisze: I won't get into my diatribe about why I think that will never happen. People were saying the same about SMTP. You know - this marginal protocol used to bridge proprietary Electronic Mail systems... -- /\_./o__ Tomasz Sterna (/^/(_^^' http://www.xiaoka.com/ ._.(_.)_ im:[EMAIL PROTECTED]
Re: [jdev] My GSoC project : to continue the PyMSNt development.
Daniel Henninger wrote: I don't disagree from the client perspective. But my philosophy has always been to make XMPP as great as it can be, then everyone else will eventually decide that they need to use XMPP and not some proprietary garbage. I won't get into my diatribe about why I think that will never happen. Aside from saying why are people still using IE6 and even IE5? ;) I've always been a big proponent of let them use what they want, we'll do what we can do make the world able to communicate better. That doesn't mean trying to tell someone your client blows, use this instead. Personally I see no problem with transport work as part of the GSoC. HOWEVER I do agree that, to me, the greater spirit of the XMPP involvement would be to learn more about XMPP and improve upon it directly. Can that be done by improving upon existing transports? Maybe. In an ideal world, it could be awefully nice to see a project in which some sort of XEP gets implemented and improved upon, or some sort of new XEP concept gets written. Really I have nothing against transports. However, my focus is on making native XMPP technologies as powerful as possible. Personally I'd rather support some fun project like MSN-like emoticons over XMPP than just bridge to a closed technology. But that's just my opinion. :) Either way, the PyMSNt project idea could always be suggested over in the Python GSoC stuff as well. True. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [jdev] My GSoC project : to continue the PyMSNt development.
Hi Florent, After a discussion, James told me : Your primary goal should be to update PyMSNt to support the latest Jabber standards. This means XEP-0144 for exchanging contacts, 172 for nicknames and 85 for chat state notification. Well, xep-85 has been done for ages (http://el-tramo.be/files/pymsn-t/chatstates.diff), it just wasn't ever reviewed or committed. That's also a very minimal project. I think james also did XEP-144 before (or maybe I hacked something together, I forgot). I know I experimented with Psi to get it working properly (i.e. automatic roster syncing), but I never committed that code. Even if you implement xep-0144 in pysmn-t completely, client support is still very basic (I'm not even sure if there's another client except Psi that implements it). I think the general consensus was that we needed a different protocol for gateway/roster interaction, which would allow the gateway to manage (a portion of) the roster itself. I also think I implemented nickname support in PyMSN-t, and that it got accepted into mainline, but again, it's been so long that my memory is vague. I think the real remaining work would be to move PyMSN-t to use PEP for its extended presence (avatars etc.), but I'm not sure how interesting that is as a project. A secondary goal would be to update PyMSNt's MSN code to use the latest MSN protocol. This would remove that annoying message about upgrading that appears on login. Also it would allow access to newer protocol features, even if they aren't implement for a while. I never really got that upgrading message, but maybe i just have messages turned off. How many new features are there that need to be implemented? As far as I know, all the functionality that maps onto jabber (avatars, chat, groupchat, chat states) is already present in pymsn-t. cheers, Remko
Re: [jdev] My GSoC project : to continue the PyMSNt development.
2008/4/6, Remko Tronçon [EMAIL PROTECTED]: As far as I know, all the functionality that maps onto jabber (avatars, chat, groupchat, chat states) is already present in pymsn-t. Missing features: * VoIP/video: for this it is probably the best to forward to another service similar to TokBox and MeBeam (maybe a new XEP is needed for this?). It should work this way. You call with your Jingle enabled Jabber client to a contact on the transport. The transport forwards your Jingle session request to the external service (MeBeam, TokBox, or something new). This service should get a Jingle interface besides the Flash interface on the website. When this service receives your request from the transport, it will open a Jingle session with you and it will notify the transport about this. The transport will also receive the URL which your MSN contact needs to open. Thus your MSN contact needs to open his browser and you can simply use your Jabber client without noticing any difference with a voice/video chat with a normal contact. * Reliability always can be better * Cache to store messages when your contact is offline. When the contact comes online, these messages should be sent. * Add support for all PEP XEPs (User Nickname, User Tune, User Activity, User Location...). Of course not all of these can be mapped to similar features in MSN, but it is common use in the MSN world to pollute your nickname with this stuff. IMO it is a very good idea to contribute to this pollution as it will make Jabber clients a better choice for people to connect to MSN...I want to see more messages like this one: http://coccinella.im/node/223 ;-) * Add support for webdav file transfers. It will be very nice if people can send their files using webdav services like http://in.solit.us/ This kind of file transfer can be much faster for downloading and/or uploading and may be a compelling reason for people who regularly transfer large files to switch to a Jabber client. The advantage also is that this kind of file transfer is easy to keep compatible with the MSN protocol; when Microsoft changes the file transfer protocol, you still can send files using webdav! -- Mvg, Sander Devrieze.
Re: [jdev] My GSoC project : to continue the PyMSNt development.
I just sent my application, I can edit it until tomorrow, and after with mentors' authorizations. I think the real remaining work would be to move PyMSN-t to use PEP for its extended presence (avatars etc.), but I'm not sure how interesting that is as a project. It is interesting for me :-), I'm agree for this goal. * VoIP/video: for this it is probably the best to forward to another service similar to TokBox and MeBeam. * Cache to store messages when your contact is offline. When the contact comes online, these messages should be sent. * Add support for webdav file transfers. These sound good as well. I'm new to Jabber/Python programming so I can't do all the above, but I need to define long enough deliverables. Thanks for you help. Florent
Re: [jdev] My GSoC project : to continue the PyMSNt development.
On Sat, Apr 5, 2008 at 4:28 PM, Florent [EMAIL PROTECTED] wrote: I know I come a bit late to propose this Summer of Code subject, but trust me I dream to do it, I have a real interest in it other than earning money from Google. Applications close this Monday (7th) so you've still got plenty of time :-P James thinks this is a fantastic idea., I stay available for your questions/opinions via mail or IM (at the same address) while I write my application. I don't have a ton of spare time unfortunately, but as the maintainer of some of the other python transports you're more than welcome to post on the py-transports list for help, and I'll try and answer as best I can. I'd also like to see the MSN transport updated, so I'm pretty likely to respond :-) -- - Norman Rasmussen - Email: [EMAIL PROTECTED] - Home page: http://norman.rasmussen.co.za/
Re: [jdev] My GSoC project : to continue the PyMSNt development.
2008/4/5, Norman Rasmussen [EMAIL PROTECTED]: Applications close this Monday (7th) so you've still got plenty of time :-P Yes, I'm doing it ;-) you're more than welcome to post on the py-transports list for help, and I'll try and answer as best I can. I'd also like to see the MSN transport updated, so I'm pretty likely to respond :-) Thanks ! It's encouraging.
