MSN Protocol documentation

Johann Prieur johann.prieur at
Fri Feb 1 15:54:15 EST 2008

On Feb 1, 2008 9:34 PM, Mariano Guerra <luismarianoguerra at> wrote:

> On Feb 1, 2008 9:25 PM, Johann Prieur <johann.prieur at> wrote:
> > Hi,
> >
> > Before writing pages of worthy documentation, I'd like that we get some
> > orientation :
> >
> > - What is our priority in terms of protocol version? Is it worthy to
> take
> > time to document older versions of MSNP? Should we only focus on the
> latest
> > version? Should we choose some editorial style defining clearly what are
> the
> > changes between versions ("transition" pages)?
> I think we should focus on MSNP15 (the latest AFAIK), so we have one
> protocol
> version well documented. If a new one come up, we should still work to
> complete the MSNP15 documentation, when its complete we can move to the
> next one if it add some significant features, if it doesn't, then we can
> wait
> until a major new version.

I share the same point of view.

> >  - What do you think YOU can bring in term of documentation? The goal
> here
> > is to define some tasks and assign them to volunteers so that we don't
> > replicate what another is doing and start getting a shape of what's
> coming.
> I guess the pymsn guys have almost all the MSNP15 protocol covered, we
> should
> hear what they have to say ;).
>  If there is some part still missing on their implementation I would
> love to try to
> investigate about it.
> So I guess we should document what they already know :P
> PS: emesenelib implementation is of MSNP13, some thigs are shared with
> MSNP15 so
> dx (the other developer) and I can document some of that parts and let
> pymsn et al
> document the parts that are particular to MSNP15.
> what do you think?

I'm one of the pymsn developers :)

Personally, I worked on reverse engineering most of the services then
implemented in pymsn, but I'm not the only one and maybe another one here
can do a better work than me. I bet what people can "document" is more
people-related than library or client related. We need to attribute task to
people, not project, really.

-------------- next part --------------
An HTML attachment was scrubbed...

More information about the Openim mailing list