GNOME Bugzilla – Bug 315341
open gnomemeeting2 for phone-number in beagle-search
Last modified: 2018-07-03 09:49:52 UTC
please integrate gnomemmeeting2 use from best's query result list. Gnomemmeeting2 (currently unstable) will support SIP. I see telephone numbers are shown, among other contact info from evo AB, why not show video chat too and let gnomemmeeting can call both (phone and videchat) via SIP, simply calling gnomemmeting -c <number>|<URI>? Note: it's adviceable to let user enable explicitely the use of it, since in some cases the use of some provider (SIP) are charged when used thanks, Cosimo.
Allowing gnomemeeting to call directly from Best will cause the same trouble with "enqueue for mp3 files". http://bugzilla.gnome.org/show_bug.cgi?id=169948 As beagle becomes more and more useful, users demand integration with various frontends and someone might want to use some other tool for calling phone numbers. The beagle people might want to come up with a way of specifying application integration (which would be some sort of an extended mime-type/application database).
I look at a single best result like the representation of a'closure' of my query agaist the item (file/chat session/mail/...), so I'd like to work on the item in as more way as possible, according to some rules. ie: item is a chat session with a person. I'd like to view the session's log and to work on the person's information in my addressbook. But the same issue of #169948 will apply to evolution and gaim too. Why Should I (as a generic user) use evolution or gaim? Best should completely remove any sort of linkage in results, at this point. I think such sort of integration should be managed as Gnome, with mimetypes, components or whatelse, instead of as beagle/best (lots of application would appreciate such thing IMHO). Where it should be discussed proficuosly? (I actually think it cannot not be discussed already somewhere)
Valid points. Leave a pointer here if the discussion moves anywhere else (e.g. beaglewiki). There was a similar problem with opening of email files http://bugzilla.gnome.org/show_bug.cgi?id=313185 thankfully, mails are (mostly) returned by specific mail backends, so the backends can store in the index the information on which client to use for open/view operations. (same applies to gaim). For this particular bug, gnomemeeting, if there is a specific backend then we can use a similar solution for hits from gnomemeeting. That still the question of opening "phone numbers" not from gnomemeeting but from evo/kdepim address books.
(keep present that I do not know beagle internals, I've just taken a look to cvs) I do not think mimetypes are the best choice, it's more appropriate an URI scheme, since it's a resource not data to be opened like a mailbox with message/rfc822 as opposite to mailto:user@domain In this case, beagle (or even better, the PIM application?) should associate each AB entry with a list of possible mimetypes or URI (depending on if it returns directly a jpg or point to a resource). with the couple (data, mimetypeOrURI) it's quite easy to handle things if no fixme:client is present into indexed data. As far as I understood fixme:client is (present as property in a single Indexable. What is needed IMHO is a greater granularity, fixme:client is too narrow to handle things where each property can be handled differently. Maybe a default Indexable.Property as uri:Email1:-> mailto: PIM data is the best example that cames to mind with etherogeneus information as opposed to mailbox for which fixme:client works correctly.
sorry, I forgot the last part of the chain: it seems freedesktop.org hasn't any proposal for URI scheme handling, like for mimetypes and .desktop. From some mail they probably are working on it now. anyway gnome VFS should help, not as a solution (it's for file handling) but .... don't know about KDE.
sorry for the noise :) I write it just for chronicle: For gnome a gconf key /desktop/gnome/url-handlers query suffices, knowing the uri to use. callto: handler is defined by gnomemeeting exactly like http is defined by mozilla (defaults to epyphany or aim by gnome-remote).
The generic action stuff is starting to get fleshed out: http://freedesktop.org/wiki/Standards_2fmime_2dactions_2dspec That's the right way to handle things like "enqueue mp3" or "call contact".
I've read that spec before posting the last comments; I realized that a mp3 representation is completely different from a telephone number representation. Anyway do the best thing (TM) and thanks for beagle :), c.
Is there a standard URI scheme that we could use for encoding phone numbers? If so, we could just throw the URI at the system to be handled in whatever manner it wishes, but I don't want to add this if it means that we have to hardcode gnomemeeting if we can avoid it.
That's reasonable, that's the why I looked for gconf keys for it. For how I understand the problem, beagle might simple ignore the format of the URI, only understand wich uri schema is and delegate it to the gconf-defined application. Anyway: IIRC there are a bunch of de facto and de iure URI schema. At least callto:, sip: and h323: are widely used. Callto: are used by skype netmeeting (and other MS stuff, i think) and supported by gnomemeeting. h323: and sip: usualy by all apps supporting the relative protocol. Keep present that an URI for VoIP services represents something more that a mere telephone number. It's the way to contact an entity in the Net according with some other information about how contact, to be contacted or whatelse. The simplest instance of it is sip:1234 wich contact the configured server/PBX requesting to call extension/number 1234. the same is for h323 and callto.
Maybe what i'm working on will be of some interest to you : http://julien.quicheaters.org/ . It's a very small addition to the "preferred applications" applet that allows users to choose which are their preferred apps for various VoIP protocols. Comments more than welcome !
Beagle is not under active development anymore and had its last code changes in early 2011. Its codebase has been archived (see bug 796735): https://gitlab.gnome.org/Archive/beagle/commits/master "tracker" is an available alternative. Closing this report as WONTFIX as part of Bugzilla Housekeeping to reflect reality. Please feel free to reopen this ticket (or rather transfer the project to GNOME Gitlab, as GNOME Bugzilla is deprecated) if anyone takes the responsibility for active development again.