[JDEV] Finding someone's JID
How do I find someone's JID in a distributed system. Any ideas. A similar question would be, how do I find someone's email address. One way would be for the clients to support a field for the user to enter another server name of where the search would take place. I could search a user at xyz.com (having a JUD), while I am connected to jabber.org. Can this work right now ? What are the privacy issues involved here. Any other ideas. Regards, Ashvil ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
[JDEV] pub/sub protocol...
Hello, I just read the pub/sub draft at , http://www.jabber.org/jeps/jep-0024.html I found it very interesting. Is this mechanism functional? Can I use it to build applications on top of it?If not now, when can we expect this? Regards, Ritu ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
[JDEV] Jogger question
A quick questions about Jogger (sorry to ask on the JDEV list - is it just me, or is there no contact info at jogger.jabber.org?) It is suggested that you add '[EMAIL PROTECTED]' to your roster. I have done that, but the authorisation message doesn't come back from that exact JID, so the Jogger bot still shows up as pending (even though I get messages in my client saying jogger.jabber.org is online, there is no 'userid@' part to the JID). Is there any way around this? Do other clients handle it in some special way? Thanks, Michael. ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
Re: [JDEV] Jogger question
I have been just dealing with the pending and have wondered about a fix... but it does the samething on my site so its not a j.o quirk On Mon, 2002-04-22 at 03:28, Michael Brown wrote: A quick questions about Jogger (sorry to ask on the JDEV list - is it just me, or is there no contact info at jogger.jabber.org?) It is suggested that you add '[EMAIL PROTECTED]' to your roster. I have done that, but the authorisation message doesn't come back from that exact JID, so the Jogger bot still shows up as pending (even though I get messages in my client saying jogger.jabber.org is online, there is no 'userid@' part to the JID). Is there any way around this? Do other clients handle it in some special way? Thanks, Michael. ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev -- JID: [EMAIL PROTECTED] ,/\, / \\. /| /| /''\___/ /''\__/ |/ /''\__/|/ \\ ./ `\/ http://www.openaether.org ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
Re: [JDEV] Emoticons: guidelines
Yep good idea, although I like the idea of sending along info about emoticons that are actually used in a message so they can be turned on and off incase (0) is defined as an emoticon (like in msn) but someone wants to send a snippet of code and not have a bit converted to an emoticon. It could also be negotiated before the conversation started; then only 'shared' emoticons are available, and the information doesn't need to be sent along with each message within the conversation. With a client which actually supports rich text/xhtml, should the emoticons get translated, or should they actually be sent along as image references? -David Waite ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
Re: [JDEV] Emoticons: guidelines
I thought about it a bit (hmm, actually a lot ;) ) and I started to like the idea. So to reduce the overhead the message could be sth. like: message type=chat to=[EMAIL PROTECTED] from=[EMAIL PROTECTED] bodyThis is a emoticon containing message :) (L) ;) :D/body x xmlns=jabber:x:econ econ text=(L) icon=luv/ econ text=:) icon=smile/ econ text=;) icon=wink/ econ text=:D icon=grin/ /x /message Yep also I think it can be shortened by a few more characters like this message type=chat to=[EMAIL PROTECTED] from=[EMAIL PROTECTED] bodyThis is a emoticon containing message :) (L) ;) :D/body x xmlns=jabber:x:econ econ txt=(L) ico=luv/ econ txt=:) ico=smile/ econ txt=;) ico=wink/ econ txt=:D ico=grin/ /x /message I should even make it shorter by omitting the smileys from the x element because they explain themselves. In this example the overhead would be reduced to 3/4!! So the example would be: message type=chat to=[EMAIL PROTECTED] from=[EMAIL PROTECTED] bodyThis is a emoticon containing message :) (L) ;) :D/body x xmlns=jabber:x:econ econ text=(L) icon=luv/ /x /message Yep very good point, so only the non-obvious emoticons would be in the x element, but i also think that if there are emoticons in the message but no non obvious ones the message should be sent with an empty x element to signify that there are emoticons in the message to be replaced, e.g. message type=chat to=[EMAIL PROTECTED] from=[EMAIL PROTECTED] bodyThis is a emoticon containing message :) ;) :D/body x xmlns=jabber:x:econ/ /message Richard ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
Re[2]: [JDEV] Emoticons: guidelines
snip Thats all good in theory but what about people who are behind firewalls and proxy's? And what about the unneccessary bandwidth it takes up, not just in the xml but having to download those images, for something like emoticons isnt it better just to have a way of defining that something is an emoticon and what it represents so particular clients can display emoticons that better go with a particular clients graphical style, and also whats to stop abuse of this by either embedding enormous images that take ages to download or an image with silly dimensions, also i will cause problems where people use a lots of emoticons within a message, something like emoticons i dont think is best delt with by embedding it in this way. It also allows the sender to determine the receivers IP address (if they retrieve the image) which is not good snip Rich Thomas Parslow (PatRat) E-Mail/Jabber: [EMAIL PROTECTED] ICQ: 26359483 ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
Re: [JDEV] pub/sub protocol...
I asked the same question last week. There are several implementations, see http://www.pipetree.com/jabber/ for pointers. -R Ritu Khetan wrote: Hello, I just read the pub/sub draft at , http://www.jabber.org/jeps/jep-0024.html I found it very interesting. Is this mechanism functional? Can I use it to build applications on top of it?If not now, when can we expect this? Regards, Ritu ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
Re: [JDEV] Emoticons: guidelines
Reply inline: - Dave Richard Dobson wrote: As you all saw, my initial proposal was purely receiver-based (i.e., the receiving program converted anything interesting-looking into an icon), but it looks to me like you're all trying to figure out some standard way of integrating non-text elements into messages :-( In that case, my proposal is simple - use an embedded element: message to=[EMAIL PROTECTED]This is a x xmlns=htmlimg src=http://dave.tj:8080/icons/envelope.png; alt=message//x containing x xmlns=htmlimg src=http://dave.tj:8080/icons/2emoticons.png; alt=two emoticons//x./message Any new client (text-only or non-text-only) will be able to support this quite easily, and any existing client won't be too difficult to modify to accomodate this convention. In other words, it has all the advantages of HTML ... because ... ahem ... it ... well ... _is_ HTML ;-) Dave Cohen [EMAIL PROTECTED] Motto: Never invent anything you don't have to :-) Thats all good in theory but what about people who are behind firewalls and proxy's? People who are behind firewalls and proxies can upload their favorite emoticons to GeoCities, and have their clients put in references to there automatically. And what about the unneccessary bandwidth it takes up, not just in the xml but having to download those images, Well, if you _really_ want to use whatever emoticon the recipient already has (presumably, from his own Jabber client installation), you can just use src=envelope.png src=mail.png along with any other likely names the graphic is likely to have, and maybe include a default src=http://somewhere/myenvelopeimage.png; attribute, in case the guy's client doesn't have any such icon. This still prevents the formation of a standard set of emoticons for Jabber, that all clients must support, and whose interpretation (and therefore the implementation of the icons by different clients) is guaranteed to lack uniformity. It also means that every time we add standard emoticons, clients without support for that particular emoticon will be left in the cold. We can always have a reference set of emoticons at http://img.jabber.org/emoticons/ and have clients make hyperlinks referenced there by default, but we're maintaining the capability for anybody to send any emoticon he may want to send, without being limited by the emoticon approval process that's going to develop if we try to standardize emoticons directly. for something like emoticons isnt it better just to have a way of defining that something is an emoticon and what it represents so particular clients can display emoticons that better go with a particular clients graphical style, I demonstrated above that this isn't a concern if we use an HTML IMG tag (since if the sender wants you to use your default emoticon for something - i.e., it's not important that you see the exact same emoticon that he sees when he composes the message - he can list a local (assumed to originate on your machine) URL before the URL of his emoticon). and also whats to stop abuse of this by either embedding enormous images that take ages to download or an image with silly dimensions, Karma stops many bad things in the Jabber world :-) ...and the silly dimensions problem can be solved client-side by anybody who wishes to restrict the dimensions of incoming images. I see no reason to use an infrerior solution simply because the more general solution requires a bit of protection on the part of the receiver. also i will cause problems where people use a lots of emoticons within a message, Yes, I'm sure you will cause a lot of problems, sending too many emoticons within a message ;-P However, naming standard emoticons doesn't lessen the load on the receiver's client's rendering engine - or even on his 'net connection, if he doesn't store emoticons locally. (Even a client that _does_ store some emoticons locally is likely to reference another repository out on the 'net, unless it decides to include some method for updating its local repository whenever new emoticons are standardized ... or unless the client developer decides to use update.jabber.org to broadcast a new version of his client every time a new emoticon is added. As you can probably guess, the situation has the capability of getting rather silly. I'd strongly suggest not trying to standardize within Jabber something which isn't even a standard outside of Jabber: let people go with whatever conventions they like, and the world will be a much better place. If the ISO ever decides to standardize emoticons, I'll be the first to recommend using the standard in Jabber.) something like emoticons i dont think is best delt with by embedding it in this way. Obviously, I'd tend to disagree ;-) This is another good enhancement but I think is better for embedding images that are only going to be sent spairingly, like someone sending a picture of their cat or something inline in the im
Re: Re[2]: [JDEV] Emoticons: guidelines
LOL ... people tend to get way to concerned about privacy, IMHO :-( Anyway, the same thing I said about getting around firewalls happens to avoid exposing your IP addy, so I guess all our privacy advocates won't be using their clients' internal repositories. (Maybe privacy-conscious clients should use the j.o-hosted emoticons by default?) - Dave Thomas Parslow (PatRat) wrote: snip Thats all good in theory but what about people who are behind firewalls and proxy's? And what about the unneccessary bandwidth it takes up, not just in the xml but having to download those images, for something like emoticons isnt it better just to have a way of defining that something is an emoticon and what it represents so particular clients can display emoticons that better go with a particular clients graphical style, and also whats to stop abuse of this by either embedding enormous images that take ages to download or an image with silly dimensions, also i will cause problems where people use a lots of emoticons within a message, something like emoticons i dont think is best delt with by embedding it in this way. It also allows the sender to determine the receivers IP address (if they retrieve the image) which is not good snip Rich Thomas Parslow (PatRat) E-Mail/Jabber: [EMAIL PROTECTED] ICQ: 26359483 ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
Re: [JDEV] Emoticons: guidelines
On Mon, Apr 22, 2002 at 09:17:24AM -0400, Dave wrote: People who are behind firewalls and proxies can upload their favorite emoticons to GeoCities, and have their clients put in references to there automatically. That sounds like a pain in the rear from the users' point of view. I actually think that just having a client side configuration that defines regexps to replace with graphics would be interesting enough. That way the user isn't constrained to a small number of icons bundled with their client. When sending the icons, via some method, to a remote client. Who should be responsible for checking that the images don't uncompress (format permitting) into a 10Gb file that causes a remote DoS ? My guess would be the client is responsible... Hmm, I think I just answered my own question. -- Dave Turner http://figroll.com/ msg05476/pgp0.pgp Description: PGP signature
Re: [JDEV] Emoticons: guidelines
- Original Message - From: Dave [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, April 22, 2002 2:17 PM Subject: Re: [JDEV] Emoticons: guidelines Reply inline: - Dave People who are behind firewalls and proxies can upload their favorite emoticons to GeoCities, and have their clients put in references to there automatically. And you expect normal people to this ?? (normal people as in non-programmers/web devs, people like new computer users, new people to the internet who just want to chat to their friends) It also requires that people have their own webspace if they want to use emoticons. And if you mean a client should auto-upload them, then that is completely unnecessary complexity for something simple like emoticons. All that needs to be done is standardise a standard set of emoticon codes so each client will know what emoticon should be used. And what about the unneccessary bandwidth it takes up, not just in the xml but having to download those images, Well, if you _really_ want to use whatever emoticon the recipient already has (presumably, from his own Jabber client installation), you can just use src=envelope.png src=mail.png along with any other likely names the graphic is likely to have, and maybe include a default Using the filename to try and tell what emoticon is being used is completely unworkable, and I dont think I have to explain why, but if anyone requires a clarification feel free to email me. src=http://somewhere/myenvelopeimage.png; attribute, in case the guy's client doesn't have any such icon. This still prevents the formation of a standard set of emoticons for Jabber, that all clients must support, Why does it stop the formation of a standard set of emoticons ?? As long as the icons that are being used represent what they are supposed to. All we are trying to standardise here is a way for each client to know what each emoticon code means not a single standard set of emoticon graphics. and whose interpretation (and therefore the implementation of the icons by different clients) is guaranteed to lack uniformity. It also means that every time we add standard emoticons, clients without support for that particular emoticon will be left in the cold. We can always have a reference set of emoticons at http://img.jabber.org/emoticons/ and have clients make hyperlinks referenced there by default, but we're maintaining the capability for anybody to send any emoticon he may want to send, without being limited by the emoticon approval process that's going to develop if we try to standardize emoticons directly. Yep there can always be a reference set of emoticon graphics for client dev's to start from or use. for something like emoticons isnt it better just to have a way of defining that something is an emoticon and what it represents so particular clients can display emoticons that better go with a particular clients graphical style, I demonstrated above that this isn't a concern if we use an HTML IMG tag (since if the sender wants you to use your default emoticon for something - i.e., it's not important that you see the exact same emoticon that he sees when he composes the message - he can list a local (assumed to originate on your machine) URL before the URL of his emoticon). But again using filenames is unworkable, filenames of emoticons will unlikely be always the same. and also whats to stop abuse of this by either embedding enormous images that take ages to download or an image with silly dimensions, Karma stops many bad things in the Jabber world :-) and the silly dimensions problem can be solved client-side by anybody who wishes to restrict the dimensions of incoming images. I see no reason to use an infrerior solution simply because the more general solution requires a bit of protection on the part of the receiver. Im sorry but I think embedding a massive bit of HTML code into the message everytime an emoticon is encountered is the inferior solution, that should be restricted to the reason previously stated as it dramatically increases the size of the xml. also i will cause problems where people use a lots of emoticons within a message, Yes, I'm sure you will cause a lot of problems, sending too many emoticons within a message ;-P it will cause problems, you know what i meant. However, naming standard emoticons doesn't lessen the load on the receiver's client's rendering engine - or even on his 'net connection, if he doesn't store emoticons locally. (Even a client that _does_ store some emoticons locally is likely to reference another repository out on the 'net, unless it decides to include some method for updating its local repository whenever new emoticons are standardized ... or unless the client developer decides to use update.jabber.org to broadcast a new version of his client every time a new emoticon is added. As you can probably guess, the situation has the capability
Re: Re[2]: [JDEV] Emoticons: guidelines
- Original Message - From: Dave [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, April 22, 2002 2:25 PM Subject: Re: Re[2]: [JDEV] Emoticons: guidelines LOL ... people tend to get way to concerned about privacy, IMHO :-( Anyway, the same thing I said about getting around firewalls happens to avoid exposing your IP addy, so I guess all our privacy advocates won't be using their clients' internal repositories. (Maybe privacy-conscious clients should use the j.o-hosted emoticons by default?) - Dave Just because you arnt worried about it it does not mean other people arnt and that they shouldnt have the right to protect their privacy not to mention security. Also hosting the emoticons on j.o servers will waste lots of j.o's bandwidth when it does not need to be. Also doing emoticons in a better way than yours does not introduce any of these problems in the first place. ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
Re: Re[2]: [JDEV] Emoticons: guidelines
On Mon, 22 Apr 2002, Richard Dobson wrote: Also hosting the emoticons on j.o servers will waste lots of j.o's bandwidth when it does not need to be. I bet there are users and/or client developers who want to customize their emoticons... my smiley shall look different from yours... ;-) so no server stored emoticons. Regards ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
Re: Re[2]: [JDEV] Using jabber for an application
I just updated the page at docs.jabber.org so that it points to the new locations. Still much to be done on the documentation front Peter -- Peter Saint-Andre email+jabber: [EMAIL PROTECTED] weblog: http://www.saint-andre.com/blog/ On Sun, 21 Apr 2002, Thomas Parslow (PatRat) wrote: URL:http://docs.jabber.org/ is the authoritative source for documentation of all sorts, much of it with working examples. If you'd like more complete working examples, check out the source code for the open source jabberd and/or Gabber and/or Jarl. See also: http://www.jabber.org/protocol/ More up to date documentation. Shouldn't docs.jabber.org point to there or something? Thomas Parslow (PatRat) E-Mail/Jabber: [EMAIL PROTECTED] ICQ: 26359483 ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
Re: Re[2]: [JDEV] Emoticons: guidelines
- Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, April 22, 2002 4:16 PM Subject: Re: Re[2]: [JDEV] Emoticons: guidelines On Mon, 22 Apr 2002, Richard Dobson wrote: Also hosting the emoticons on j.o servers will waste lots of j.o's bandwidth when it does not need to be. I bet there are users and/or client developers who want to customize their emoticons... my smiley shall look different from yours... ;-) so no server stored emoticons. Exactly that was part of my point. ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
Re: Re[2]: [JDEV] Emoticons: guidelines
Okay, now before you read my response to a previous message (which answers all your concerns), can anybody come up with any more problems with the HTML IMG tag approach? That was certainly a rather major salvo of bashing you folks put up ;-P - Dave Richard Dobson wrote: - Original Message - From: Thomas Parslow (PatRat) [EMAIL PROTECTED] To: Richard Dobson [EMAIL PROTECTED] Sent: Monday, April 22, 2002 11:08 AM Subject: Re[2]: [JDEV] Emoticons: guidelines It also allows the sender to determine the receivers IP address (if they retrieve the image) which is not good Yup another bad thing, didnt think of that but thats definitely a problem, not to mention having to have an HTTP server running in a client, which makes for too much bloat (for my liking) and also potential security problems as well as firewall incompatibility. ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
RE: [JDEV] Emoticons: guidelines
here's something to ponder: emoticons can be viewed as a special case of a more generic capability. Let's call it jabsters (c). In essence a jabster is a textual description that has a meaning different from the text itself -- a short cut if you will. Emoticons are one example, all of the other little acronyms like BTW, IANAL, TIA, RTFM are short cuts too (but they aren't emoticons). If I type BTW, what can't it come up as By the way on the other client? I suggest that we have a more generalized format to accommodate other short-cut uses. We also need a mechanism to identify which jabster sets are available on each client (a capabilities exchange). We don't want one person typing LOL on a client assuming it will come out as laughing out loud and the other client uses a different jabster set that translates LOL to lots of luck. A more esoteric application can be for the non-tradition IM, like from human-to-device. Perhaps I want to IM my coffee machine and say Turn On. The coffee machine could see this as a jabster and translate it to the relevant command string for the device. Here the jabster is a translation from a human readable command to a device command. Similar to emoticons? I think so. So when we finalize how we want to handle emoticons, lets also think about the more generic case and perhaps cover it, too while we are at it. ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
Re[4]: [JDEV] Emoticons: guidelines
Okay, now before you read my response to a previous message (which answers all your concerns), can anybody come up with any more problems with the HTML IMG tag approach? That was certainly a rather major salvo of bashing you folks put up ;-P - Dave It's just way more complicated then it needs to be. It creates security problems which the rest of Jabber has been designed to prevent. And it requires people to upload emoticons they want to use or rely on sort of central store. All an emoticon system needs to do is replace certain pieces of text (such as :)) with brightly colored friendly little graphics, why add a requirement for each client to have to connect to a web site and download them for each message? IMHO, no extra protocol enhancements are needed, although it would possibly be useful to define a standard set (I'm not really convinced even this is needed but it wouldn't hurt). Also, as has already been mentioned, most clients will probably want to provide they're own emoticon graphics which fit in with the rest of the UI. Thomas Parslow (PatRat) E-Mail/Jabber: [EMAIL PROTECTED] ICQ: 26359483 ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
Re: [JDEV] retrieving name from server
Server details? --temas On Sun, 2002-04-21 at 20:16, Jason Anderson wrote: I'm trying to retrieve the name of the logged-on user from the jabber server, but I can't figure it out. Here's what I'm doing: -connect -authorize -set presence -try a query like this: iq type='get' to='localhost' query xmlns='jabber:iq:register'/ /iq The result is: iq to=zwei@localhost/Home from=localhost type=result query xmlns=jabber:iq:register instructionsChoose a username and password to register with this server./instructions password/password name/name email/email key00c46204ce5a85a2a4ea0a6d6249642446006454/key registered/registered /query /iq I have a name set, but it is never returned to me. Maybe I should be using the browse protocol. Can anyone suggest what the problem might be? Thanks, jason ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
Re: [JDEV] Finding someone's JID
This works fine in many clients right now. I often search jabber.com's JUD for informatino. The privacy issue is moot when the user knowingly uploads their vCard to the public JUD they are on. The JUD could also have been made internal. On another note, we've looked at mechanisms to try and tie JUDs together, and it's not a pretty problem. Maybe something will come along that can do it. --temas On Mon, 2002-04-22 at 02:04, Ashvil wrote: How do I find someone's JID in a distributed system. Any ideas. A similar question would be, how do I find someone's email address. One way would be for the clients to support a field for the user to enter another server name of where the search would take place. I could search a user at xyz.com (having a JUD), while I am connected to jabber.org. Can this work right now ? What are the privacy issues involved here. Any other ideas. Regards, Ashvil ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
Re[2]: [JDEV] Emoticons: guidelines
here's something to ponder: emoticons can be viewed as a special case of a more generic capability. Let's call it jabsters (c). In essence a jabster is a textual description that has a meaning different from the text itself -- a short cut if you will. Emoticons are one example, all of the other little acronyms like BTW, IANAL, TIA, RTFM are short cuts too (but they aren't emoticons). If I type BTW, what can't it come up as By the way on the other client? I suggest that we have a more generalized format to accommodate other short-cut uses. We also need a mechanism to identify which jabster sets are available on each client (a capabilities exchange). We don't want one person typing LOL on a client assuming it will come out as laughing out loud and the other client uses a different jabster set that translates LOL to lots of luck. A more esoteric application can be for the non-tradition IM, like from human-to-device. Perhaps I want to IM my coffee machine and say Turn On. The coffee machine could see this as a jabster and translate it to the relevant command string for the device. Here the jabster is a translation from a human readable command to a device command. Similar to emoticons? I think so. So when we finalize how we want to handle emoticons, lets also think about the more generic case and perhaps cover it, too while we are at it. I'd find that sort of thing incredibly annoying (ok, I also find emoticons annoying but this would be more so:). If I write BTW I probably want the user at the other end to see BTW. Maybe if I'm lazy (which I am;) I might appreciate some sort of auto complete in my client but it would just be a pain if the remote client went and changed what I'd written. Thomas Parslow (PatRat) E-Mail/Jabber: [EMAIL PROTECTED] ICQ: 26359483 ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
Re: [JDEV] whom to contact for starting a new project @jabberstudio.org
Like zariok said, email or jabber me ([EMAIL PROTECTED] for both). --temas On Sat, 2002-04-20 at 06:00, Gunjan Kakani wrote: Hi, I am searching for the right contact to start a new project on Jabberstudio.org (and in turn for Jabber community :-) If anyone knows..please point me... Cheers~ -GC ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
Re: [JDEV] msn transport
There have been many complaints filed against msn-t, unfortunately the developer seems to be gone now. Any takers? =) --temas On Thu, 2002-04-18 at 02:56, anand joglekar wrote: hi, i am getting inconsistant response from msn transport. when i 1. create a new local id 2. register with msn transport 3. create buddies 4. send message the message goes thru to msn client (on other pc) however, if i logout from jabber and log in again, i can't get thru. i still receive messages sent from msn client to jabber client, but not the other way. presence still works ok. has anybody seen similar behaviour ? is there any correction to setup? i am using jabber 1.4.2 on linux (redhat 6.1), winjab and jim clients. the jabber server runs on a local linux machine, connected to net thru proxy. regards, anand ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
Re: [JDEV] retrieving name from server
JOSS 1.4.2 and 1.4.1 (tried both) running on RedHat 7.2 I don't have any server problems that I know of. I'm asking because I'm working on a client. jason Thomas Muldowney wrote: Server details? --temas On Sun, 2002-04-21 at 20:16, Jason Anderson wrote: I'm trying to retrieve the name of the logged-on user from the jabber server, but I can't figure it out. Here's what I'm doing: -connect -authorize -set presence -try a query like this: iq type='get' to='localhost' query xmlns='jabber:iq:register'/ /iq The result is: iq to=zwei@localhost/Home from=localhost type=result query xmlns=jabber:iq:register instructionsChoose a username and password to register with this server./instructions password/password name/name email/email key00c46204ce5a85a2a4ea0a6d6249642446006454/key registered/registered /query /iq I have a name set, but it is never returned to me. Maybe I should be using the browse protocol. Can anyone suggest what the problem might be? Thanks, jason ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev . ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
Re: [JDEV] Emoticons: guidelines
Reply inline: - Dave Dave Turner wrote: --MIdTMoZhcV1D07fI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 22, 2002 at 09:17:24AM -0400, Dave wrote: People who are behind firewalls and proxies can upload their favorite emoticons to GeoCities, and have their clients put in references to there automatically. That sounds like a pain in the rear from the users' point of view. ...not if the client does that all for you automatically :-) I actually think that just having a client side configuration that defines regexps to replace with graphics would be interesting enough. That was my other original idea (take a peek at my first post on this subject, a few days ago). However, the sender may want a little more control over the interpretation of his message, and having the receiving client decide those regexps takes that control away from the sender (although receiving clients may want to implement the above anyway, as it doesn't clash with any standards whatsoever). Now, if the sender is going to decide those regexps (as I presume you intend), you'll have to invent a new namespace for all this gunk, and send info on how to parse the message with the message itself. It sounds more and more like a kludge the more I think of it :-( That way the user isn't constrained to a small number of icons bundled with their client. The user is only constrained by the number of icons he can find/create URLs for :-) When sending the icons, via some method, to a remote client. Who should be responsible for checking that the images don't uncompress (format permitting) into a 10Gb file that causes a remote DoS ? My guess would be the client is responsible... Hmm, I think I just answered my own question. That whole question is moot if you're using an existing standard (like HTML IMG tags), rather than stewing your own kludge: web browsers are well-equipped to handle large amounts of data - they either take up all your virtual memory, or crash ;-/ --=20 Dave Turner http://figroll.com/ --MIdTMoZhcV1D07fI Content-Type: application/pgp-signature Content-Disposition: inline -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8xBaowM5fO8TkIMkRAjW0AJ9O/7WsbeXbMUhzau8zz2hzsqPxoACgh087 0IIWYTlnWF0x9067p2Wqezk= =g+iV -END PGP SIGNATURE- --MIdTMoZhcV1D07fI-- ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
Re: [JDEV] Emoticons: guidelines
Dave wrote: As you all saw, my initial proposal was purely receiver-based (i.e., the receiving program converted anything interesting-looking into an icon), but it looks to me like you're all trying to figure out some standard way of integrating non-text elements into messages :-( In that case, my proposal is simple - use an embedded element: message to=[EMAIL PROTECTED]This is a x xmlns=htmlimg src=http://dave.tj:8080/icons/envelope.png; alt=message//x containing x xmlns=htmlimg src=http://dave.tj:8080/icons/2emoticons.png; alt=two emoticons//x./message Any new client (text-only or non-text-only) will be able to support this quite easily, and any existing client won't be too difficult to modify to accomodate this convention. In other words, it has all the advantages of HTML ... because ... ahem ... it ... well ... _is_ HTML ;-) Another option would be to use namespaces to embed another type of data within the message, i.e. message to=[EMAIL PROTECTED]html xmlns=http://www.w3.org/TR/rec-xhtml; xmlns:ex='emoticon-namespace'This is a ex:message/ containing ex:two-emoticons/./html/message But this has the disadvantage of not being visible on non-emoticized clients ex:smiley/. -David Waite ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
Re[4]: [JDEV] Emoticons: guidelines
Okay, now before you read my response to a previous message (which answers all your concerns), can anybody come up with any more problems with the HTML IMG tag approach? That was certainly a rather major salvo of bashing you folks put up ;-P Well if you want my opinion, it's simply too much for emoticons.. what you're suggesting is more along the lines of for example an MMS message.. wich is something that could give jabber a little edge over other messaging systems maybe, but it should be defined for that purpose then (along with things like sound). Not emoticons.. If I look at all the discussion about it here I think the most far we could get is define a list of emiticons used by jabber. Clients can simply choose to support property clients emoticons like MSN then or not (after all you ussually know to wich gateway or user you send a message :) ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
Re: [JDEV] Emoticons: guidelines
Reply inline: - Dave Richard Dobson wrote: - Original Message - From: Dave [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, April 22, 2002 2:17 PM Subject: Re: [JDEV] Emoticons: guidelines Reply inline: - Dave People who are behind firewalls and proxies can upload their favorite emoticons to GeoCities, and have their clients put in references to there automatically. And you expect normal people to this ?? (normal people as in non-programmers/web devs, people like new computer users, new people to the internet who just want to chat to their friends) How do you suppose the file transfer thingy in Gabber works? Does the end user have to implement it all himself? I don't think so. It also requires that people have their own webspace if they want to use emoticons. ...not any worse than file transfer - and if you use any of the more-likely-to-be-found emoticons (like smiley.png), odds are that the guy receiving your message has a corresponding icon for it, so you can use a local URL, or use the j.o URL (or the URL of another emoticon repository on the 'net) ... using URLs to locate emoticons is a very clean solution, because URLs _are_ standardized, unlike emoticons. . . And if you mean a client should auto-upload them, then that is completely unnecessary complexity for something simple like emoticons. Any given client has ten million choices about how to implement emoticons if you use something standard like HTTP IMG tags. With your proposal, emoticons can only be implemented in one way, and if you want to use a cool emoticon you just downloaded from your friend, then ... well, buddy ... you're out of luck, since (assuming your emoticon is even included in the standard), your buddy probably has a different image for that emoticon, so if your emoticon has some subtle little feature that gives extra flavor to your message (what emoticons are intended for), that extra flavor will be lost in transit. What's worse, is that people who use one client will think that the emoticons should look the same on their chat windows and on their buddies' chat windows. With your proposal, there's no way for a user to make sure that happens, short of sending inline images. All that needs to be done is standardise a standard set of emoticon codes so each client will know what emoticon should be used. ...and anybody who wants to use a non-standard emoticon will be severely out of luck :-( And what about the unneccessary bandwidth it takes up, not just in the xml but having to download those images, Well, if you _really_ want to use whatever emoticon the recipient already has (presumably, from his own Jabber client installation), you can just use src=envelope.png src=mail.png along with any other likely names the graphic is likely to have, and maybe include a default Using the filename to try and tell what emoticon is being used is completely unworkable, and I dont think I have to explain why, but if anyone requires a clarification feel free to email me. If the j.o repository has specific filenames associated with specific images, clients are likely to support that convention. If you include the j.o URL as a backup src attribute in all emoticons you send that also have a home at j.o, then any emoticon _not_ implemented with the same filename on the recipient's system will be drawn from the j.o repository, which is just fine. src=http://somewhere/myenvelopeimage.png; attribute, in case the guy's client doesn't have any such icon. This still prevents the formation of a standard set of emoticons for Jabber, that all clients must support, Why does it stop the formation of a standard set of emoticons ?? It's stops the formation of a standard set of emoticons, simply because it obviates the need for a synthetic standard. You'll notice that none of the other IM systems agree on a standard set of emoticons, either. The reason is simple: ANSI and the ISO have refused to get involved (not that I can blame them: emoticons are - by their very nature - very emotional, and emotions are hard to standardize). As long as the icons that are being used represent what they are supposed to. ...but the icons shown in AIM and in MSNM for the same smileys in text look radically different, and convey different emotions - you can easily confuse somebody by implying one thing in the text of your message, but sending an emoticon that conveys an entirely different message :-( All we are trying to standardise here is a way for each client to know what each emoticon code means not a single standard set of emoticon graphics. Well, for those applications where any standard smiley will do, send an IMG tag with a src attribute for smiley.png, and (if desired) a backup src attribute for img.j.o/emoticons/smiley.png or whatever. For all other applications, you can use whatever smiley you want. and whose interpretation (and therefore the implementation of
Re: [JDEV] Emoticons: guidelines
- Original Message - From: Dave [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, April 22, 2002 10:46 PM Subject: Re: [JDEV] Emoticons: guidelines also there is no way of stopping the sending person from sending them in the xml in the first place, How about sending: message to=annoying_emoticon_sender@whereever_he_happens_to_be type=normalPlease stop sending me these stupid emoticons. They add nothing to your messages, and simply make my Jabber client work overtime to find and display appropriate images. There are a bunch of relatively standard emoticons which you can use as-is, but please don't bother me with all that MSN crap. (Crap is a technical term - it refers to this shit you keep sending me.)/message to whoever refuses to purify his XML streams to you? Seriously, how does your system [stop] the sending person from sending them in the xml in the first place? Well because of the fact that all the added information is in its own x element its a LOT easier to separate out of the message being sent, this pub/sub stuff may be able to help turning it on and off, also the sending client could browse the recipients address to see if it supports that x element and only send it if it does. ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
Re: Re[2]: [JDEV] Emoticons: guidelines
Reply inline: - Dave Richard Dobson wrote: - Original Message - From: Dave [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, April 22, 2002 2:25 PM Subject: Re: Re[2]: [JDEV] Emoticons: guidelines LOL ... people tend to get way to concerned about privacy, IMHO :-( Anyway, the same thing I said about getting around firewalls happens to avoid exposing your IP addy, so I guess all our privacy advocates won't be using their clients' internal repositories. (Maybe privacy-conscious clients should use the j.o-hosted emoticons by default?) - Dave Just because you arnt worried about it it does not mean other people arnt and that they shouldnt have the right to protect their privacy not to mention security. I think the second part of my message (the one quoted above by you) answers your concerns. Also hosting the emoticons on j.o servers will waste lots of j.o's bandwidth when it does not need to be. I figured you'd probably come up with another salvo. . . Anyway, I don't think j.o will object to hosting a reference set of emoticons. (If it did, I'm sure plenty of other interested parties would gladly supply their own repositories; they probably will anyway, even if j.o supplies one.) Also doing emoticons in a better way than yours does not introduce any of these problems in the first place. Of course doing them in a better way than mine should not introduce any of the problems mine has. All I'm pointing out is that the method you seem to be proposing does in fact introduce many new problems without solving some of the fundamental problems that the method I've described (and fleshed out a in much more detail thanks to your rather constructive criticism) addresses quite elegantly, so I'd hesitate to call that method any better than the one I'm proposing. ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
Re: [JDEV] Emoticons: guidelines
Reply inline: - Dave David Iodice wrote: here's something to ponder: Oh, no ... not _another thing_ to ponder ... please ... I'm already busy pondering Mr. Dobson's assault on HTTP IMG tags ;-/ emoticons can be viewed as a special case of a more generic capability. Let's call it jabsters (c). In essence a jabster is a textual description that has a meaning different from the text itself -- a short cut if you will. Emoticons are one example, all of the other little acronyms like BTW, IANAL, TIA, RTFM are short cuts too (but they aren't emoticons). If I type BTW, what can't it come up as By the way on the other client? This should all be handled _only_ by the receiving client. When it receives LOL, it can translate that into Laugh Out Loud. It can also translate :-) into a smiley (and :) into a noseless dude making a half-hearted attempt at smiling), or it can give you a tooltip when you hover over RTFM with your mouse saying Read The F'in' Manual!!! However, none of this has to do with our protocol for emoticon representation (and indeed, none of it belongs in any particular IM protocol suite, for reasons I've already outlined - we lack the authority to standardize this sort of stuff ... if we keep trying to abuse a monopoly we don't have, we'll end up like Apple). I suggest that we have a more generalized format to accommodate other short-cut uses. We also need a mechanism to identify which jabster sets are available on each client (a capabilities exchange). We don't want one person typing LOL on a client assuming it will come out as laughing out loud and the other client uses a different jabster set that translates LOL to lots of luck. Something about the above screams complexity, at least IMHO. A more esoteric application can be for the non-tradition IM, like from human-to-device. Perhaps I want to IM my coffee machine and say Turn On. The coffee machine could see this as a jabster and translate it to the relevant command string for the device. Here the jabster is a translation from a human readable command to a device command. Similar to emoticons? I think so. So when we finalize how we want to handle emoticons, lets also think about the more generic case and perhaps cover it, too while we are at it. Ideally, the coffee machine's Jabber client would understand the turn on command and translate that into whatever language it uses to turn itself on (it can show itself pictures of women sans clothing, for all I care), but once again, we're out of the realm of what translation algorithms belong in an IM protocol. The whole idea behind IM protocol standardization is that everything external adapts itself to the protocol without all sorts of built-in translation within the protocol itself. ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
Re: [JDEV] Emoticons: guidelines
- Original Message - From: Dave [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, April 22, 2002 10:46 PM Subject: Re: [JDEV] Emoticons: guidelines also those sort of devices can currently display .png or .gif, only .wbmp, should these be not allowed to use emoticons? No everyone should be able to. I'm sorry, but I don't speak English too well. Maybe you can clarify that? Just bear in mind that if you're trying to tell me that the Portable Network Graphic format isn't standard enough (but the proprietary GIF format (or worse, the Windows BitMaP format) is, presumably), I won't hear of it: Jabber is an open standard, and including proprietary image formats in it is bordering on heresy. Since when has .wbmp meant an image is a windows bitmap, it stands for Wireless Bitmap the only image format supported on WAP phones, which is currently is the only real thing that has GPRS capability, so I dont know where you got Windows Bitmap from, also .wbmp is not a proprietary format by any means it is part of the wap standards, I said all of this because your method assumes that the receiving client (in this case a WAP phone) definately supports the image format you are sending it, and if you are sending .png, .gif, or .jpg a WAP phone would be unable to support it, this is YAP (yet another problem) with your system. ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
Re[6]: [JDEV] Emoticons: guidelines
-- Original Message -- Reply inline: - Dave That's a legitimate complaint - HTML is too generalized if all you want is a small set of standardized emoticons. However, the buck won't stop there, and I can guarantee you that much. Well, if you want to send your emoticons as XHTML there already is the xhtml element for you. It's meant so that you can decide how you want the message to look. In how far to support this is up the the makers of the clients. Emoticons is something else though.. they don't have to look the same on every client.. it's interpretted the way the developer of the client likes (and/or based on the feedback he gets from his users ofcourse). If I look at all the discussion about it here I think the most far we could get is define a list of emiticons used by jabber. Clients can simply choose to support property clients emoticons like MSN then or not (after all you ussually know to wich gateway or user you send a message :) so the best we can hope for, according to you, is to simply return to our chaos of different IM systems supporting different emoticons, with one added dimension - our own set of standard emoticons, ready to compete with all the other standard emoticons ;-P Well what I hope we can come to is, that when we're sending emoticons from one jabber client to the other there is some form of standardization. For example let's not have that one client decides (h) is the standard icon for a heart, and the other (L). When sending a message to a property-IM system like MSN, the client can ofcourse detect this and adapt emoticons accordingly (same for receiving), but again, this is a decision that's in the hands of the client developers. I can imagine some outthere would say: I don't care about MSN, I'll just stick to jabber. I do propose however an element in the message indicating no emoticons should be rendered at all, and a mechanism for one client to tell the other it doesn't support emoticons. This way we'll have a diversity of clients.. so everyone can have one they like :) It's an easy implementation, provides for possible interoperatability with systems like Yahoo! and MSN (up to the developer) and no weird custom namespaces. I can have a simple client saying: hello :) and a more advanced client rendering it the way I like it with the emoticon I like. I can paste a piece of code to a friend without having weird smileys show up all over it. And ofcourse Dave, if you want to send me a message containing a wonderfull piece of XHTML with images of the some of the most beatifully rendered emoticons inside it you can *still* do that.. just don't forget to supply the alternative bodymessage/body message as well, cause not every client outthere likes to render XHTML. ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
Re: Re[2]: [JDEV] Emoticons: guidelines
Okay, it's a 2 vs. 1 here ... how about if one of you echoes _my_ messages instead of the other's? That should even things a bit ;-) - Dave Richard Dobson wrote: - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, April 22, 2002 4:16 PM Subject: Re: Re[2]: [JDEV] Emoticons: guidelines On Mon, 22 Apr 2002, Richard Dobson wrote: Also hosting the emoticons on j.o servers will waste lots of j.o's bandwidth when it does not need to be. I bet there are users and/or client developers who want to customize their emoticons... my smiley shall look different from yours... ;-) so no server stored emoticons. Exactly that was part of my point. ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
