[standards-jig] calendaring?

Casey Crabb debug at nafai.dyndns.org
Wed Mar 13 21:08:23 UTC 2002

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.


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.
> _______________________________________________
> Standards-JIG mailing list
> Standards-JIG at jabber.org
> http://mailman.jabber.org/listinfo/standards-jig

More information about the Standards mailing list