Re: Legacy URI Translation Service

On Mar 15, 2006, at 5:16 AM, Daniel Henninger wrote:

> Likewise, a jabbber client could register itself as the handler of  
> aim: and various things, expecting that if you clicked on one of  
> those url's it would auto-translate it.

yup-yup. That's the idea.

> The only problem I can see is, how would it know "which aim to  
> translate"?  What if you were running multiple aim transports?

I think that's a special fringe case. Ideally the user would be able  
to pick which transport would handle the URI.

> It's a very loopy type of question in the sense of, well maybe the  
> transport could announce it's support of that URI so the client has  
> an idea ...

Absolutely. Support for this feature would have to be discovered.

> but then again what if you have two that announce their support?

See above.

>   Overall it's something that I'd love to see, but I'm not sure how  
> the logistics of it work.  A lot of the URI's I can cheat with in  
> PyAIM.  For example, add buddy is easy.  Chatrooms are also fairly  
> easy because I can simply send an invite.  but yeah, there's  
> definitely a lot of URIs that I can do nothing with.  Beyond the  
> message one, there's the infamous buddy icon set one.  Yeah, I  
> could set the buddy icon on the aim side, but then how does the  
> jabber vcard get updated so that next time the vcard is retrieved,  
> pyaim doesn't write right over the newly set icon?

Well, I could always write up a prototype and see what happens. :)  
The thing is, what would be the best way to implement it? Would an ad- 
hoc command mechanism be the way to go, or perhaps something more  
lightweight like the jabber:iq:gateway protocol?

If anyone has any suggestions about this, please speak up.

> On Mar 14, 2006, at 11:33 PM, Robert B Quattlebaum, Jr. wrote:
>
> > (For the sake of clarification for those reading this from the jig- 
> > standards list, the PyAIM transport has an ad-hoc command called  
> > 'aimuritranslate', which allows you to 'execute' a aim URI)
> >
> > So I was thinking about the "aimuritranslate" ad-hoc command a  
> > bit, and I was trying to think about a possibly better/generic way  
> > to handle it. The problem is that there are some actions that  
> > can't be performed in such a way (such as joining a chat room),  
> > and some actions that you don't want to execute immediately (such  
> > as a URI which fills out a default message to be edited before  
> > being sent).
> >
> > What about having a service which would translate from the legacy  
> > URI to the XMPP IRI? This would allow the client to interpret the  
> > URI properly under all circumstances.
> >
> > For example, such a service would translate the following URI's as  
> > follows:
> >
> > aim:goim?screenname=rquat2&message=I+bow+before+your+awesomeness
> > might become
> > xmpp:rquat2@xxxxxxxxxxxxxxxx?message;body=I%20bow%20before%20your% 
> > 20awesomeness
> >
> > ...and...
> >
> > aim:gochat?roomname=MyAwesomeChatroom
> > might become
> > xmpp:MyAwesomeChatroom@xxxxxxxxxxxxxxxxxxxxx?join
> >
> >
> > This actually sounds like something that could be applied added to  
> > every legacy transport. With proper client support, this would  
> > allow a jabber client to correctly support all of those  
> > proprietary URI's!
> >
> > Such a mechanism could be useful for more than just translating  
> > legacy URI's to XMPP-IRI's. For example, you could have the  
> > returned URI not be an XMPP-IRI at all.
> >
> > Anyway, I am sending this to both the pytransports list and the  
> > jig-standards list because I think the topic has ramifications for  
> > both.
> >
> > Any thoughts?



__________________
Robert Quattlebaum
Mobile: +1(650) 223-4974
eMail:  darco@xxxxxxxxxxxx
Jabber: darco@xxxxxxxxxxxx
WWW:    http://www.deepdarc.com/