[JDEV] Re: Implementing Jabber Server in other Languages (Was RE:[JDEV]Customizing Jabber server)

Nitin Borwankar nitin at borwankar.com
Mon May 14 03:21:27 CDT 2001


Nitin Borwankar wrote:
> 
> > John Hebert wrote:
> 
> Hi John,
> 
> OK, I'll be moving to the protocol list after this.

Actually on second thoughts I don't think that'll be very productive.
I looked.

That list doesn't seem to be very active.  I could have sworn I could
hear my email message echo as it bounced around inside the cavernous
empty spaces there.
And my SMTP server went HELO and the one on the other side said
..ELO..LO..O :-)

As for the python-dev list the last message posted there appears to be
mine !!  from Mar 2000
asking if the Python-Jabber project is still active ? No reply, no more
messages. Not even an echo.
Man this stuff is spooky !

So is there really a place where protocol doc issues are being discussed
?
Python server implementation issues ? ...ssues ? ... ues ? ...

Nitin Borwankar.


> I didn't know there was a separate list for the protocol discussion,
> must have missed some messages in between.
> 
> As far as what messages the server should handle, we should step back
> and talk in terms of what functionality is considered core Jabber
> functionality and what is not.  The latter consists of issues related to
> pthreads, etherx ... ie implementation dependent and also those related
> to transports for other IM protocols.
> 
> To me the core functionality in order of importance is that which allows
> 
> 1) messaging (messages and file transfer)
>   a) 1-1
>   b) group
> 
> 2) presence subscription/notification
> 
> 3) user directory/roster/buddy lists
> 
> So IMHO, we should include those protocol enable that enable these
> functions, in the core compliance suite.
> I haven't been up to speed with all the changes happening since server v
> 1.1 but AFAIK
> these have been implementation/architecture improvements rather than
> fundamental protocol changes.
> So if I have missed or misstated something please jump in and correct
> 
> I'd be glad to provide effort and input to the actual protocol
> documentation effort.
> OK, over to the protocol list now.
> 
> Nitin
> 
> >
> > Nitin,
> >
> > All of your ideas are good and worth pursuing further. A co-worker of
> > mine, Dustin Puryear, is building the test suite. I'll speak to him
> > about a compliance test, but first I'd like to clarify some of the
> > ideas you mentioned. Specifically, what messages should the server
> > handle correctly to constitute compliance? Should this be a subset of
> > the current protocol or the entire set?
> >
> > I'd also like to find out more about the python based jabber server
> > project status. In hibernation? I'd really like to help with this.
> >
> > I was thinking however, out of consideration to jdev, that we should
> > move these threads to the protocol and python-dev mailing lists. I've
> > cc:ed those lists. What do you think? To everyone following these
> > threads, consider this an open invitation.
> >
> > Thanks,
> > John Hebert
> >
> > -----Original Message-----
> > From: Nitin Borwankar
> > To: jdev at jabber.org; jdev at jabber.org
> > Sent: 5/12/01 4:26 PM
> > Subject: Re: Implementing Jabber Server in other Languages (Was RE:
> > [JDEV] Cus tomizing Jabber server)
> >
> > Hi Iain, all,
> >
> > I have been lurking on this list but had brought up this issue on IRC
> > channels, of defining the protocol separately and building another
> > *interoperable* and *independednt* implementation so as to meet IETF
> > standards.  This was last year back when the Jabber protocol was being
> >
> > prepared for submission to the IETF as an IM standard.
> >
> > This issue, that the server implementation is the protocol definition,
> >
> > is a real problem for the future expansion of Jabber.
> > All successful widely deployed open protocols have had these two
> > efforts
> > separated.
> > A tremendous amount of effort has gone into the creation of all kinds
> > of
> > clients for Jabber but there is only one server.
> > The fact that the source code is available makes it an Open Source
> > development project, but not an open protocol development effort.  I
> > too
> > have little interest in the C implementation.  I have more interest in
> >
> > the Java and Python server implementations.
> >
> > I had begun a Python-based server development effort last year but it
> > was very prematurely truncated for personal emergencies that caused me
> >
> > to put all non-billable work aside for a long time.  I was consulting
> > for France Telecom in Brisbane Ca and was instrumental in giving very
> > positive reviews of Jabber to my boss after attending the first
> > developer bootcamp in Denver last August.  These were probably
> > ultimately forwarded to the people in France, re-inforcing their
> > opinions.  Interesting to see that France Telecom has now invested in
> > Jabber.  Great stuff!!
> >
> > I have also noticed in passing that there is a test suite being
> > developed.  If the test suite could be evolved into a protocol
> > compliance suite, that would be the best way to leverage existing
> > efforts.  Then, any new server development effort could at least meet
> > some baseline interoperability by passing the test/compliance suite.
> > In
> > time this will get documented and evolve in to the protocol definition
> >
> > doc.
> >
> > I would strongly urge Michael Bauer, and others to raise this issue at
> >
> > the business level - it will accelerate Jabber adoption exponentially.
> >
> > Jabber Inc. need not worry about the business implications - the SMTP
> > protocol is widely documented and publicised, and there are a number
> > of
> > competitiors, but Sendmail Inc. still has a largest market share by
> > far
> > in the Enterprise email server space.  So it will be of Jabber Inc.
> > not
> > to worry.  And there will also be many simple implementations of the
> > protocol adapted for different business use by different user
> > constituencies.  These will only create greater demand for the
> > commercial version.  I don't want the source for the commercial
> > version
> > but I do want the protocol effort to be separated and opened up,
> > and have wanted it for almost a year now.
> >
> > So please make this a priority, its a win-win-win all around.
> >
> > Nitin
> >
> > Nitin Borwankar
> > President and CEO, Borwankar Research Inc.
> > ntin at borwankar.com
> > 510-653-8394
> > nbor on IRC
> >
> > At 06:50 AM 5/11/01, Iain Shigeoka wrote:
> > >At 02:42 PM 5/9/2001 -0500, John Hebert wrote:
> > >
> > >>>   On second thought - David Waite's right - we have to look at
> > separating
> > >>>   protocol from server implementation.
> > >>
> > >>My point all along. Apache has the W3C. What does Jabber have? Do we
> >
> > >>need a separate jabber protocol effort separate from the server
> > devel
> > effort?
> > >
> > >Yes.  We need to separate protocol from implementation.  Most people
> > I've spoken to are at least philosophically in agreement on this
> > issue.
> > This has been a problem since Jabber has evolved as an implementation
> > that defined the protocol.  IMHO the time has really come to split the
> >
> > protocol off.  Jabber has remained coherent until now because there
> > has
> > only been one server implementation available so the implementation
> > has
> > defined the protocol.  However, as Jabber.com now as a separate server
> >
> > (albiet very closely related) and there are other efforts to develop
> > servers, a separate protocol standard is going to become essential.
> > As
> > I understand it, this is something that we can use the Jabber
> > Foundation
> > as a tool to help us accomplish.
> > >
> > >FYI, I'm very interested in the protocol and implementing my own
> > Jabber
> > server (in Java not Python) and have little/no interest in the current
> > C
> > implementation.  Reading the protocol docs from this perspective has
> > really been what's gotten me interested in better defining the
> > protocols
> > to stand alone from the implementation.  As it stands now, it is
> > pretty
> > much impossible to write a server based on the existing protocols
> > because they are incomplete.  In addition, there is no way to test
> > your
> > protocol compliance except in relationship to the current C
> > implementation.  I'm hoping to also work on addressing that issue as
> > well (standard compliance when a standard exists).
> > >
> > >-iain
> > >
> > >
> > >_________________________________________________________
> > >Do You Yahoo!?
> > >Get your free @yahoo.com address at http://mail.yahoo.com
> > >
> > >_______________________________________________
> > >jdev mailing list
> > >jdev at jabber.org
> > >http://mailman.jabber.org/listinfo/jdev
> >
> > _______________________________________________
> > jdev mailing list
> > jdev at jabber.org
> > http://mailman.jabber.org/listinfo/jdev
> _______________________________________________
> jdev mailing list
> jdev at jabber.org
> http://mailman.jabber.org/listinfo/jdev



More information about the JDev mailing list