Re: [jdev] My GSoC project : to continue the PyMSNt development.

[Sander Devrieze]

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.

[Richard Dobson]

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.

[Sander Devrieze]

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.

[Richard Dobson]

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.


Richard

Re: [jdev] My GSoC project : to continue the PyMSNt development.

[Sander Devrieze]

2008/4/10, Richard Dobson <[EMAIL PROTECTED]>:
> Norman Rasmussen wrote:
>
> > 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.
> >
>  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.

[Richard Dobson]

Norman Rasmussen wrote:
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.
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.

[Norman Rasmussen]

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.

[Sander Devrieze]

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  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.

[Norman Rasmussen]

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  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.

[Sander Devrieze]

2008/4/9, Peter Saint-Andre <[EMAIL PROTECTED]>:
> 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),

Reliable and well-integrated presence and IM is what we definitely
need and what we do not yet have in all transports. E.g. some
transports do not support JID Escaping which means end users get ugly
roster items ("[EMAIL PROTECTED]" instead of
"[EMAIL PROTECTED]").

> or do most people also require
>  the ability for file transfers,

Transport can implement XEP-0129: WebDAV File Transfers (
http://www.xmpp.org/extensions/xep-0129.html ):
1) XMPP users can send files
2) Files are stored to webdav
3) Closed network contacts get the webdav uri from the transport and
can dowload the file
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  for more
information."

> voice calls, emoticons (etc.) to go
>  across the bridge between Jabber and MSN?

Not really required: let's first make sure the basic things work *good*.

>  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.

I started to list all issues I discover with transports:
http://coccinella.im/third-party-issues

-- 
Mvg, Sander Devrieze.

Re: [jdev] My GSoC project : to continue the PyMSNt development.

[Norman Rasmussen]

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.

[Dallas Gutauckis]

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.

[Peter Saint-Andre]

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.

[Jonathan Dickinson]

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.

[Sander Devrieze]

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.

[Peter Saint-Andre]

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.

[Daniel Henninger]

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.

[Tomasz Sterna]

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]

> 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.

[Peter Saint-Andre]

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.

[Sander Devrieze]

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.

[Peter Saint-Andre]

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.

[Florent]

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.

[Sander Devrieze]

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.

[Remko Tronçon]

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.

[Florent]

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.

Re: [jdev] My GSoC project : to continue the PyMSNt development.

[Norman Rasmussen]

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/