[jdev] Gaim and gnomemeeting using jabber
richard at dobson-i.net
Wed Dec 1 09:58:57 CST 2004
>> What I would concider against the spirit of it would be to try to use it
>> to publish the voip-uri or your voip presence, rather than as you point
>> out use it to advertise the capability.
> That's what you made of it. Noone (including the starter of this topic)
> ever made that a requirment.
Urm as far as I read it the starter of this topic wants to have a specific
functionaility of being able to express voip-presence, not simply the
> Then why do you insist on PubSub?
Because thats how you provide a mechanism to express voip-presence, one of
the requirements the starter of this topic specified. Its fine to do
intiation of the actual session as you suggest, infact in my last email to
the starter of this topic I have described the three tasks he is trying to
accomplish all in one little presence hack, only Task 3 is not possible
currently without new protocol, the others he can do fine without creating
1) advertise a client is voip capable (this should be done using JEP-0030
2) initiate a chat with another voip capable client (this should be done
using JEP-0020, then JEP-0066).
3) advertise your voip-presence as something separate from the normal
im-presence (there is nothing currently to do this, a protocol based on
pubsub would seem the best solution to this task).
> Pubsub is dynamic (duh). It's our data that's not. Thus there is no need
> for PubSub.
Urm but is is dynamic, the part about expressing your voip-presence is
completely dynamic, i.e. when you start a call it will change to "incall"
when you finish it will change to "notincall", I dont understand why you
dont think this is not dynamic???
>> As pointed out above you wouldnt even want it to be a uri, you would
>> want it to be something more generic to represent the voip presence i.e.
>> "incall" or "notincall".
> Well, the topic starter had no such goals with his proposal. He listed a
> "VoIP presence" as a potential extention. Maybe one day there will be such
> a thing (using pubsub no doubt) it's not at all important for what we want
> to accomplish. The only "presence" that matters is "enabled" or "not
> enables", 115 can do this without pubsub. This makes a lot more sense for
> what the topic starter wants to accomplish (it can work today, for
Urm yes he has specified voip-presence as a requirement, here is a quote
"But if you consider the
grand scheme of having the voip client able to notify that you're
already on a call, or in do-not-disturb mode"
But I agree with the rest of what you say that if he simply drops the
requirement of voip-presence (Task 3 above) he can do the rest following
standard protocols now without any problems (Tasks 1 and 2).
More information about the JDev