Re: [CoreTeam]Re: [DotGNU]To What Degree Jabber?

[Barry Fitzgerald]

I just have a point of order to bring up:

I think we should accept all protocols that seem to be useful, but
establish a pecking order.  Make XML-RPC and SOAP a priority but then
add other protocols through the abstraction layer - this seems to make
the most sense to me.  However, if people don't want to use the
abstraction layer, the direct protocol should be accessible to them (in
some cases and in some languages, it already is) so that the developers
have options.  Whereever possible, the native library and abstraction
layer should use the same code. 

However, the reason that I say this is because we should not limit
ourselves to only using specific protocols.  This is more of an
implementation issue that should be left up to the projects.  We should
only list protocols that we endorse and the order in which we endorse
them.  I think that the industry definition of webservices is already
too restrictive, we should not fan the flames so to speak. 

Therefore, I propose that we look to the following order:  XML-RPC,
SOAP, jabber:middleware, BEEP, and Apex.  

This fits with prior decisions, and from a pragmatical aspect, fits with
implementational constraints.  XML-RPC and SOAP are more widely known
protocols.  jabber:middleware gains marketshare through jabber developer
propogation.  And I suspect that Beep and Apex are up-n-comers in the
protocol game.  In all DotGNU projects, the emphasis should be this
list, in FIFO order.  XML-RPC aspects should be developed into projects
first and foremost.  Then other protocol implementations after that.  In
an abstraction layer, I could see this happening by either setting an
environment variable or passing a parameter in a function call.  Perhaps
there are even other methods to do this (exporting an object property?) 
but that can be worked out by the GNU-RPC team, if it still exists or
should exist.  The only exception to this would be if a DotGNU project
absolutely found that one protocol further down the list had extremely
tangible benefits when compared with the others prior to it in the
list.  For instance, if jabber:middleware was the only protocol that fit
a particular programs needs - and neither XML-RPC nor SOAP did so in a
convenient way, it would be possible for that program to only use
jabber:middleware.  

Does this approach make sense to people?  This way, we can beat other
webservice framework developers through flexibility.  I think, in the
end, the one who wins this is going to be the team that provides the
most options to the most developers.

        -Barry



David Sugar wrote:
> 
> I believe Bradley is correct that collectivily (GNU Enterprise,
> phpGroupWare, GNUCOMM) we have already agreed to use XMLRPC for GNU
> groupware standards.  Beyond that, there was some discussion of using SOAP.
> 
> The problem Jabber tries to solve is an important one, and one not
> solved by pure RPC systems since they are not designed as peer to peer.
>  It is clear we do need some peer to peer solution we can all agree
> upon, whether it's to use Jabber's protocols or something else (Beep
> perhaps?).
> 
> I have no issue in principle with Jabber, as there are both free
> software implimentations of jabber servers and there is no proprietary
> aspect to the protocol itself.  However, this needs to be discussed with
> the other projects as well.
>