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

Sun May 13 13:29:42 CDT 2001

> John Hebert wrote:

Hi John,

OK, I'll be moving to the protocol list after this.
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