[standards-jig] calendaring?

Dave dave at dave.tj
Wed Mar 13 22:52:06 UTC 2002


The browse method is rather shorthanded, in that it was designed for a
client to query a server to find out what it supports.  Servers aren't
very picky about where to direct what, and the browse protocol reflects
that.  I'm looking for a solution that enables the client to make all
the routing decisions.  Furthermore, "enhancing" the browse method to
support clients would probably create a large argument later, when
somebody actually got around to proposing a more flexible method -
"What's this new gunk needed for?  We already have the browse method,
and it does almost everything you need ... let's just enhance the browse
method further. . ."  Enhancing a server-initiated method to emulate
the functionality of a client-controlled method wouldn't be easy, and
I'd view it as a fundamental weakness in the Jabber protocol suite.

Just my opinion (which I rarely hesitate to give), as usual,
Dave Cohen <dave at dave.tj>


Julian Missig wrote:
> 
> Oh, yeah, definitely. But this browse method is something we could have
> servers do right now without having to make a new protocol...
> 
> That said, yeah, I would love to see a routing protocol.
> 
> On Wed, 2002-03-13 at 16:08, Casey Crabb wrote:
> > I think having the client tell the server where to route the packet 
> > would probably be a more flexible way to go. Especially if the clients 
> > could request a packet be sent to more than one client. Thats something 
> > that I've wanted for a while. Of course having the client specify would 
> > be more complicated and would require further additions to the protocol.
> > Food for thought I guess.
> > 
> > --
> > Casey
> > 
> > Julian Missig wrote:
> > > That's where feature negotiation comes in. I'll write up some of my
> > > ideas in more detail, but basically, even with simple browsing we could
> > > have the server be properly routing this stuff... the server browses to
> > > the clients as they connect, and if a message with an extension is sent
> > > to the JID with no resource, the server will look at all the resources
> > > for one which reports supporting that namespace.
> > > 
> > > Julian
> > > 
> > > On Wed, 2002-03-13 at 15:50, Dave wrote:
> > > 
> > >>The problem is that if you have a message-only Jabber client and a
> > >>message-and-videoconferencing Jabber client, you have no way of telling
> > >>the Jabber server that videoconferencing requests should be sent to
> > >>your videoconferencing client, while text messages should be sent to
> > >>your text-only client.  Now, if we add a calendaring client to the mix,
> > >>we've just made our problem even bigger, because we have no way of
> > >>telling the server to send calendaring events to our calendaring client.
> > >>
> > >>In other words, you're right: there's nothing "requiring" a Jabber client
> > >>to implement a non-core feature (or even the "core" feature of text
> > >>messaging), but if your client doesn't implement a particular feature,
> > >>users of that client won't have an easy way of using that feature without
> > >>opting for another client for _all_ their Jabber interaction.  THAT is
> > >>what I'm referring to as the problem here.  I'm working on a solution
> > >>with my Jabber proxy, but I'd like to see my proxy obsoleted by some
> > >>server-side ability to route XML data to different resources based on
> > >>rules submitted by the clients.  I'd like to have my calendaring Jabber
> > >>"client" actually be a module in my calendaring application, designed
> > >>to interact with the Jabber world.  I can then have a module in my
> > >>calendaring application for email interfacing (which already has very
> > >>impressive routing capabilities) too, as well as one for communicating
> > >>over my cell phone.
> > >>
> > >>Dave Cohen <dave at dave.tj>
> > >>
> > >>
> > >>Iain Shigeoka wrote:
> > >>
> > >>>On 3/5/02 8:42 AM, "Dave" <dcohen at ramapo.edu> wrote:
> > >>>
> > >>>
> > >>>>If your goal is to be able to "chat" with your calendar, I'd strongly
> > >>>>suggest using something like ChatBot, and simply making a scheduling
> > >>>>plugin.  If your goal is to integrate scheduling functionality into
> > >>>>a Jabber client, why not just embed a calendaring client (for some
> > >>>>reasonably standardized scheduling protocol) into your Jabber client?
> > >>>>As far as I can see, the more "stuff" we add to the Jabber protocol,
> > >>>>the fewer choices we'll all have for fully-functional clients
> > >>>>(since a "fully-functional" Jabber client will actually have to be a
> > >>>>fully-functional video conferencing client, as well as a fully-functional
> > >>>>scheduling client, as well as a fully-functional group management client,
> > >>>>as well as, of course, a fully-functional IM client, and my experience
> > >>>>
> > >>>This is not the intent of the Jabber protocol setup.  Other than the basic
> > >>>Jabber protocols, all other protocols are optional.  There may be
> > >>>"competing" protocols which address the same problem in different ways.  As
> > >>>long as you support the "core" jabber protocols, you are a "full jabber
> > >>>client".  All extension protocols are designed to provide standard ways of
> > >>>adding additional functionality.  They are not required or even suggested
> > >>>for every client to implement.
> > >>>
> > >>>All this goes to say that within reason, the more protocols the better.  A
> > >>>calendering protocol would be a nice addition.
> > >>>
> > >>>-iain
> > >>>
> 
> 
> _______________________________________________
> Standards-JIG mailing list
> Standards-JIG at jabber.org
> http://mailman.jabber.org/listinfo/standards-jig
> 




More information about the Standards mailing list