MSN Protocol documentation
johann.prieur at gmail.com
Fri Feb 1 15:54:15 EST 2008
On Feb 1, 2008 9:34 PM, Mariano Guerra <luismarianoguerra at gmail.com> wrote:
> On Feb 1, 2008 9:25 PM, Johann Prieur <johann.prieur at gmail.com> 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
> > time to document older versions of MSNP? Should we only focus on the
> > version? Should we choose some editorial style defining clearly what are
> > changes between versions ("transition" pages)?
> I think we should focus on MSNP15 (the latest AFAIK), so we have one
> 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
> 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
> > 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
> I guess the pymsn guys have almost all the MSNP15 protocol covered, we
> 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