Re: [JDEV] Jabber Client Design Tutorial
> Julian (x-virge) and I were discussing client design > yesterday and I think you are a prime example of > our discussion. There is a problem with Jabber, > in general it's not everyones first IM client. Great! I've always wanted to be a prime example :-) It's true I guess, but it's not the only reason that people are turned off Jabber. Really, the Jabber clients are very immature compared to the clients for the commercial services. This is not meant as any disrespect to the client authors - none of them have the resources of AOL or Microsoft behind them, but this doesn't matter to the end user. To convince them to switch services, the clients have to be at least 90% as good as the one they are switching from. Also, the argument about switching from one of the proprietary services also applies to switching between Jabber clients, so it would be nice to have some sort of consistency between them if possible. > Users have generally been on another large network (AIM, ICQ, > MSN, Yahoo!) before they come to Jabber. Despite their not > liking the system (that's why they came to Jabber isn't it? ;-]) > they tend to like their client, usually because they are comfortable > with it. That's true in some cases. My reason for wanting to move from ICQ to Jabber is more political than dissatisfaction with ICQ in the first place. I would prefer that Jabber would become a system that attracts users by what it has to offer, rather than just waiting for people to get sick of their existing system. > If i had to guess, by reading your doc (which I did), > you come from ICQ. If you had read my doc there should be no guessing involved. I am clearly biased toward the ICQ interface as I have said since it is the one I have used the longest (as it was the first one available), but that is not to say that I have never used any other products. I use Lotus Sametime all day at work, and have MSN installed. At the moment I am using Go Messenger as my Jabber client, and have used JabberIM quite a lot. > Now I say this with absolutely no direction to you, but I find > ICQ's UI absolutely atrocious, even AIM's is pretty wicked, > so is Yahoo!, MSN is partially acceptable, but has many > disparities. I say all that from a purely UI centric view. I was hoping for something a bit more substantial I have to admit. Saying "xyz is atrocious" is not really productive, unless you can back up your opinion with examples, and better options. ICQ's interface is a bit confusing for a first time user, I have to admit, but for power users it is great. AIM and MSN are much more basic clients, since their services lack many of the features that ICQ and Jabber offer - such as offline messages - but there are things that we can and should learn from them. > The idea of a doc to help get people rolling > beyond the protocol is a great idea and there are many > odd things about Jabber that merit UI discussion (iq:browse, > it could easily have a browser view like winjab, but could > also be a simple tree view like the explorer sidebar), but I > would encourage you to weigh in many options, not a > single view. Sure - more opinions the better - that's the whole aim. That and to give client developers ideas that they may not have thought of. Client design doesn't have to be as black and white as the protocol, but there are definitely some rules you should go by. Let me look into iq:browse, I'm not exactly sure how it is used or the best way to present it. > Open it up, and don't suggest that only one thing > is correct, because you never will please everyone, > especially in the IM world. Never aim to please everyone... Michael. ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
Re: [JDEV] Jabber Client Design Tutorial
> I, of course, agree with temas here. I have quite a few > comments already, but I'll look at your guide a bit > more thoroughly tomorrow and make a reply. Thanks, that would be great. > One major thing that struck me was that you said > server hard disk space won't be wasted by history. Did I? Depends on what you mean by "wasted" I guess. Data is going to take some space obviously. I will go back and review that section actually. I cut and pasted it from an old note and maybe it could be better worded. It's not really a UI issue, I just wanted somewhere to put my rant. My main point, is that the history should not be saved locally. > My logs from the past two years total 50 megs. Really? My ICQ history database for the last 4 years is only 20MB (more once it's indexed). Have you tried zipping it? > 50 megs... 100 000 users on a server. Even 10 000 users on > a server. Would you care to pay for that much disk space? Nope, but I'd be happy to pay for 50MB for my own account. I think you miss my point(s) somewhat... - It doesn't actually have to be on the same physical machine, just somewhere that all clients can access it. - It doesn't have to be enabled on every server, or it can be an optional (chargeable) feature. - Admins can fix a limit to archive sizes - most people won't want to refer to a chat session 4 years old. - Not all people will want to save message history. - Disk space gets cheaper every year. - The advantages outweigh the storage issues. > And remember, these messages are all plain text. > Just wait until we have rich text formatted messages. Good point...I was thinking that ICQ was rich text, but looking at it now, it just seems to save the font and colours. I guess there are a few options - wear the extra resources, or convert to plain text maybe. I wouldn't get hung up on the space issue... A good design is more important at this stage. Michael. ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
Re: [JDEV] URL form of JID?
> > I'd much rather add a query to the URL indicating the action: > > > > jabber:[EMAIL PROTECTED]?action=message # send IM (default action) > > jabber:[EMAIL PROTECTED]?action=roster # add to roster > > > > jabber:[EMAIL PROTECTED]?action=chat # join a chat room > > I think this makes a lot of sense, as it doesn't muddy the > JID part of the URL and is a clean and flexible way of doing > things. And it's also a format we're familiar with (HTTP GET URLs). > > Ironically, I guess the achilles heel is the flexibility: > > jabber:[EMAIL PROTECTED]?action=chat # join a chat room > > vs > > jabber:[EMAIL PROTECTED]?action=join # join a chat room jabber:[EMAIL PROTECTED]?action=chat joining a chatroom could get confusing. I would have assumed it would have started a line-by-line private chat (as opposed to sending a "normal" message- see http://docs.jabber.org/jpg/html/main.html#REFMESSAGE for details). Having two "chat" types in Jabber does confuse things a little... Michael. ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
Re: [JDEV] help for storage module
Dear Benoit: I try it , it is good for MySQL, and I how to add a backend for oracle. I need what file from Oracle. thanks a lot. > hi, > > > I need to change XDB storage to oracle, where can I start? > you can use xdb_sql (download.jabber.org/contrib) and add a backend > for oracle. > > > Benoit. > > -- > Benoit Orihuela > IDEALX S.A.S. > ___ > jdev mailing list > [EMAIL PROTECTED] > http://mailman.jabber.org/listinfo/jdev > - This mail sent through IMP: mail.wizdomtech.com ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
Re: [JDEV] URL form of JID?
On Mon, Sep 24, 2001 at 07:44:21PM +1000, Michael Brown wrote: > > jabber:[EMAIL PROTECTED]?action=chat # join a chat room > > > > vs > > > > jabber:[EMAIL PROTECTED]?action=join # join a chat room > > jabber:[EMAIL PROTECTED]?action=chat joining a chatroom could get > confusing. I would have assumed it would have started a line-by-line Yes, hence the forced comparison ;-) > private chat (as opposed to sending a "normal" message- see > http://docs.jabber.org/jpg/html/main.html#REFMESSAGE for details). > > Having two "chat" types in Jabber does confuse things a little... There's only one chat type, but it's used in different contexts (contexts that are mostly layers that we impose with our understanding, rather than technical contexts) dj ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
Re: [JDEV] Jabber Client Design Tutorial
On Mon, Sep 24, 2001 at 06:51:01PM +1000, Michael Brown wrote: > > Also, the argument about switching from one of the proprietary services also > applies to switching between Jabber clients, so it would be nice to have > some sort of consistency between them if possible. I'd have to respectfully disagree there... I don't want a one-size-fits-all world, and I relish the diversity of clients available right now. I do have to and say that I didn't come to Jabber with any IM baggage - I wasn't a previous user of any of the commercial systems... Then again, the argument holds for other clients too - I couldn't imagine anything worse than having to use, say, MS-Outlook for my mail; a team of horses couldn't drag me away from mutt. So, I guess it boils down to the old chestnut "horses for courses" on this front.. dj ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
Re: [JDEV] Jabber Client Design Tutorial
> > Also, the argument about switching from one of the proprietary services also > > applies to switching between Jabber clients, so it would be nice to have > > some sort of consistency between them if possible. > > I'd have to respectfully disagree there... I don't want a > one-size-fits-all world, and I relish the diversity of > clients available right now. I didn't mean to imply that they should all be the same, but there is some need for *some* clients that behave in a similar manner, and provide the same function as the commercial clients in order to convert the general public. Michael. ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
Re: [JDEV] Jabber Client Design Tutorial
On Mon, Sep 24, 2001 at 09:53:46PM +1000, Michael Brown wrote: > > > > I'd have to respectfully disagree there... I don't want a > > one-size-fits-all world, and I relish the diversity of > > clients available right now. > > I didn't mean to imply that they should all be the same, but there is some > need for *some* clients that behave in a similar manner, and provide the > same function as the commercial clients in order to convert the general > public. True. I just thought it necessary to make sure my stick was still firmly in the mud. :-) dj ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
RE: [JDEV] Conference messages cut off
Just for FWIW, I am having the same exact problem with Jabber 1.4.1 using Conference 0.4.1 on a Solaris 2.7 box. Like the original poster, I had no problems on a Linux box (Redhat 7.x), and most of my open-source libs on the Solaris box came from sunfreeware.com. Steve White -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of [EMAIL PROTECTED] Sent: Thursday, September 20, 2001 11:36 PM To: [EMAIL PROTECTED] Subject: Re: [JDEV] Conference messages cut off I am also getting conference messages truncated, often at the first byte of a one-liner. Using JabberIM I will type something like: I see this problem too, looks like it is a bug in the server? And what the participants see and what I get echoed back is just: I Has anybody seen this exact behavior? Any suggestions for a fix? This is running Jabber-1.4.1 on a Solaris 8 server. I had been running on a FreeBSD system and _never_ saw this bug, then I copied the source code over to Solaris, recompiled, and now I have this annoying problem! After migration I went from having 1-3 users in a conference to 8-20 users, so at first I thought it was related to the increased number of participants, but it could just be a Solaris issue. Kevin Kadow > I noticed very similar behavior when sending a message to an offline contact > using the 1.4.1 code on a Solaris 7 machine. > However, the same exact code > (http://download.jabber.org/dists/1.4/final/jabber-1.4.1.tar.gz), compiled > on a linux box (redhat 6.2), does NOT show this behavior. > > I was forced to conclude that either something went awry during the > compilation process under solaris, or one of the open-source libraries I > installed (from www.sunfreeware.com) was responsible for this bug. > Actually, even more likely, one of the utilities from sun is responsible for > this behavior. Either way, I could not duplicate the problem under Linux. > > I know this info might not help you get it running under solaris, but at > least you wont have to be overly confused if other people tell you they > can't duplicate the problem. > > -Original Message- > From: Jens Alfke [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, September 18, 2001 3:04 PM > > Many moons ago I mentioned that the conference module often cuts off > chat messages if they contain XML metacharacters like quotes, angle > brackets, etc. In fact I've had to make my client translate those > characters into less offensive ones (like curly quotes) on the way out > to avoid hitting this bug. > > Now I found a related problem: Multi-line conference messages often > appear to get cut off after the first line. (That is, a newline is > causing message truncation just like the XML metacharacters do.) What's > weird is that the sender will (about half the time) be echoed the full > message, but other people in the chat never receive the full message. > I've looked at the raw XML on both sides to verify this. > > This is with the 1.4.1 server on Solaris. ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
RE: [JDEV] URL form of JID?
It might be messy and infinite, but should they all be "jabber:" ? I think it would make more sense as: chat:[EMAIL PROTECTED] msg:[EMAIL PROTECTED] etc. -Original Message- From: DJ Adams [mailto:[EMAIL PROTECTED]] Sent: Friday, September 21, 2001 3:38 PM To: [EMAIL PROTECTED] Subject: Re: [JDEV] URL form of JID? On Fri, Sep 21, 2001 at 11:48:52AM -0700, Jens Alfke wrote: > Is there a standard way to represent a JID as a URL (analogous to a > mailto: URL)? The most basic form would be something like > "jabber:user@host/resource" and the default action when clicked would be > to send an IM to that user. I do remember seeing examples of this in very old docu, it was something like your example, it could have been jabber://user@host/resouce but then I might be going mad. > It occurs to me that a second form would be useful for conferences / > chat-rooms, since the behavior of clicking the URL would be different > (joining the room.) AIM, I believe, uses a "?" attribute on the "aim:" > URL to distinguish between these things. This is certainly an idea, but when you consider a conference room is just one of almost an infinite variety of types of things, each with their own "default" action, to attempt to make a distinction within the format is futile. That said, perhaps in a browsing situation, the type of thing that a particular JID represents may be easier to discern because of its context within an iq:browse structure... dj ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
[JDEV] MS Passport and Open alternatives
>wow... MS is on the warpath... > >they're supposedly opening up their .Net auth system to allow other, >non-Passport, auth systems, such as from AOL or Yahoo... they would be >100% compatible with each other, so Yahoo Auth users could use Yahoo to >access Hotmail and other MSN services... > >http://www.zdnet.com/anchordesk/stories/story/0,10738,2813501,00.html > OK, a few words on this issue. Firstly, MS is not actually "opening" Passport - Passport is inherantly impossible to open in its current form as it relies upon a central authentication engine. This is why any email address can be a Passport without the address provider installing any software - MS runs the show. What they have actually said is they will allow "federation" of Passport to other organisations. Let's examine what this means: "Federation allows businesses of any size, or any other organization, to maintain the control of their local resources while still being able to interact with people, organizations and software that are not under their direct control." MS PressPass OK, so this is actually only a minor change to the current model. At the moment if you want to make your site Passport enabled, you have to go through a massive amount of paperwork to get it going, involved Microsoft actually trying out your site beforehand to ensure it works! Federation won't change this - all it does is allow companies to run their own Passport engines with the permission of Microsoft. Now they *have* realised that what the net needs is an open authentication system and they propose Kerberos to do this but what they don't mention is whether it'll be the Microsoft version or the MIT version which are of course incompatible. Second problem - they say Passport will be accessible via Kerberos. But Kerberos wasn't designed for the web, how will this work? Kerberos is also very complex, relying on networks of key distribution servers, clock synchronization etc., so it's not a piece of cake to add authentication to a product that uses Kerberos. I don't think we should say, MS has openened Passport, right that's authentication solved. It might turn out to be as open like hardware is "open" in Windows XP, where anyone can write drivers ... as long as they get permission from Microsoft first. I don't want to see this, the open community can do better. In fact I have been thinking about this :) What's needed is an open "Simple Authentication Protocol" (SAP) that has bindings to various protocols such as Jabber, SOAP, XML-RPC etc. This would allow any server to allow authentication against it simply by running a small server alongside say an email or jabber server, that responds to messages requesting authentication. It could well use Kerberos design principles and even be compatible with it to some extent - but I seriously don't think Kerb is right for this job. I described the basic model in an email a few days ago, and the content of this protocol wouldn't be hard to guess anyway. This would allow anyone to have their network address be used for authentication and single sign on without the standardisation and centralisation issues prevalent in Passport. ok, rant over. thanks for reading -mike ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
[JDEV] AIM Transport Problem
Howdy, I was told to email here with the XML messages. Basically, I have the AIM Transport installed on my server, and when I go to AIM Transport to register in the client, the server hoses out with: segmentation failed (core dumped) Here are the messages: from GDB: #0 0x080598e7 in pmalloc (p=0x81f9ff8, size=52) at pool.c:161 #1 0x08059a79 in pmalloco (p=0x81f9ff8, size=52) at pool.c:194 #2 0x0805d0ba in _xmlnode_new (p=0x81f9ff8, name=0x4017f160 "route", type=0) at xmlnode.c:49 #3 0x0805d6e3 in xmlnode_new_tag_pool (p=0x81f9ff8, name=0x4017f160 "route") at xmlnode.c:263 #4 0x0805e781 in xmlnode_wrap (x=0x8212320, wrapper=0x4017f160 "route") at xmlnode.c:832 #5 0x4016e3be in js_session_route (s=0x81f8f00, in=0x8212320) at sessions.c:50 #6 0x4016ecf5 in _js_session_to (arg=0x8212d18) at sessions.c:309 #7 0x08056466 in mtq_main (arg=0x8145670) at mtq.c:150 #8 0x080819b3 in pth_spawn_trampoline () at eval.c:41 #9 0x08082621 in pth_mctx_set_bootstrap () at eval.c:41 #10 #11 0x4006b656 in __sigsuspend (set=0x80906a0) at ../sysdeps/unix/sysv/linux/sigsuspend.c:45 #12 0x401c2e68 in res.1 () from ./dialback/dialback.so From Debug Mode: Sun Sep 23 21:55:49 2001 dnsrv.c:143 dnsrv: Read error on coprocess(1): 0 Success Sun Sep 23 21:55:49 2001 dnsrv.c:157 DNSRV CHILD: out of loop.. exiting normal Also I would like to ask.. I have the server setup, and I'm able to chat between users on my server, I can even have someone from the internet login and I can chat with them, as long as they are on my server.. However I heard it was possible to add users from other servers and be able to chat with them, this doesn't work however.. when I put in their JID, it just shows them as offline.. I'm not sure if anything has to be setup in the server for this to work, I thought I saw someone say that it's default.. Anyways this is on my home network, and I am running NAT on a Cisco 2514 router. I'm not sure maybe I have to open more ports to it? currently I have 5222, 5269 and 7000 opened up to my Linux box.. any suggestions? Hope you can help.. Thanks, I greatly appreciate it, Ciscoswitch Wayne Catterton Network Engineer Portland, OR
Re: Re: [JDEV] Non english messages solution?
Alex She convert to local, >1cn.com>:> Hi, >> >> Is there any Non english messages solution? My Friend and I use >> winjabber to chat.But we use different encoding. One is >> gb2312, the other is big5.we can not see the messages each other. >> Thanks for any info. >> >> Regards, >> >> - Lg >> >> 2001-9-21 21:38:08 >> >> -- >> Gang Liu / Vista Team / ShenZhen City / China >> Email: [EMAIL PROTECTED] & [EMAIL PROTECTED] >> Phone: +86 13923425035 >> ICQ: 70670666 >> Web: Coming >> >> ___ >> jdev mailing list >> [EMAIL PROTECTED] >> http://mailman.jabber.org/listinfo/jdev >> > > >- >This mail sent through IMP: mail.wizdomtech.com >___ >jdev mailing list >[EMAIL PROTECTED] >http://mailman.jabber.org/listinfo/jdev = = = = = = = = = = = = = = = = = = = = ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
Re: [JDEV] URL form of JID?
> Is there a standard way to represent a JID as a URL (analogous to a > mailto: URL)? The most basic form would be something like > "jabber:user@host/resource" and the default action when clicked would be > to send an IM to that user. URL identify RESOURCES - people, places, documents, stuff. mailto: identifies an e-mail address. What you do with the resource (add-it to addressbook, send mail to it) is up to the client's user interface. Imagine a web-browser where the default click action was "add-to-hotlist" instead of "open" -- wouldn't be very useful, but it would be valid. jabber:user@host/resource is a valid URI. It identifies a Jabber user in a particular context (the /resource bit). > It occurs to me that a second form would be useful for conferences / > chat-rooms, since the behavior of clicking the URL would be different > (joining the room.) AIM, I believe, uses a "?" attribute on the "aim:" > URL to distinguish between these things. A chat room is a separate resource, so you'd either say jabber:conference-name@host (this would be analogous to a mailing list in a mailto: URI) or jabberconf:name@host (create a special protocol to indicate conferences). I prefer the first alternative, since it simplifies the namespace -- but since conferences in Jabber aren't analogous to mailing lists, it might be better to have a separate protocol for them. i.e. you can have user FOO@host and conference FOO@host with no way of distinguishing them. Trying to hack in different protocol extensions through the query-part of the URI is not a good idea. The context menu for a jabber: URI should permit sending a message, adding the target to the address-book. For a jabberconf: URI it would be send a message, join the conference, add conference to address book. -- christian ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
Re[2]: [JDEV] URL form of JID?
>> > I'd much rather add a query to the URL indicating the action: >> > >> > jabber:[EMAIL PROTECTED]?action=message # send IM (default action) >> > jabber:[EMAIL PROTECTED]?action=roster # add to roster >> > >> > jabber:[EMAIL PROTECTED]?action=chat # join a chat room >> >> I think this makes a lot of sense, as it doesn't muddy the >> JID part of the URL and is a clean and flexible way of doing >> things. And it's also a format we're familiar with (HTTP GET URLs). >> >> Ironically, I guess the achilles heel is the flexibility: >> >> jabber:[EMAIL PROTECTED]?action=chat # join a chat room >> >> vs >> >> jabber:[EMAIL PROTECTED]?action=join # join a chat room > jabber:[EMAIL PROTECTED]?action=chat joining a chatroom could get > confusing. I would have assumed it would have started a line-by-line > private chat (as opposed to sending a "normal" message- see > http://docs.jabber.org/jpg/html/main.html#REFMESSAGE for details). > Having two "chat" types in Jabber does confuse things a little... > Michael. jabber:[EMAIL PROTECTED]?action=join or jabber:[EMAIL PROTECTED]?action=conference maybe? Thomas Parslow (PatRat) ICQ #:26359483 Rat Software http://www.rat-software.com/ Please leave quoted text in place when replying ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
Re: [JDEV] AIM Transport Problem
Ok... can you get the XML sent to the server in anyway? Or could you run the server with debug enabled (-D) and send the log in? --temas On Mon, 2001-09-24 at 00:22, Wayne Catterton wrote: > Howdy, > > I was told to email here with the XML messages. Basically, I have the AIM Transport >installed on my server, and when I go to AIM Transport to register in the client, the >server hoses out with: segmentation failed (core dumped) > > Here are the messages: > > from GDB: > > #0 0x080598e7 in pmalloc (p=0x81f9ff8, size=52) at pool.c:161 > #1 0x08059a79 in pmalloco (p=0x81f9ff8, size=52) at pool.c:194 > #2 0x0805d0ba in _xmlnode_new (p=0x81f9ff8, name=0x4017f160 "route", type=0) at >xmlnode.c:49 > #3 0x0805d6e3 in xmlnode_new_tag_pool (p=0x81f9ff8, name=0x4017f160 "route") at >xmlnode.c:263 > #4 0x0805e781 in xmlnode_wrap (x=0x8212320, wrapper=0x4017f160 "route") at >xmlnode.c:832 > #5 0x4016e3be in js_session_route (s=0x81f8f00, in=0x8212320) at sessions.c:50 > #6 0x4016ecf5 in _js_session_to (arg=0x8212d18) at sessions.c:309 > #7 0x08056466 in mtq_main (arg=0x8145670) at mtq.c:150 > #8 0x080819b3 in pth_spawn_trampoline () at eval.c:41 > #9 0x08082621 in pth_mctx_set_bootstrap () at eval.c:41 > #10 > #11 0x4006b656 in __sigsuspend (set=0x80906a0) at >../sysdeps/unix/sysv/linux/sigsuspend.c:45 > #12 0x401c2e68 in res.1 () from ./dialback/dialback.so > > From Debug Mode: > > Sun Sep 23 21:55:49 2001 dnsrv.c:143 dnsrv: Read error on coprocess(1): 0 Success > Sun Sep 23 21:55:49 2001 dnsrv.c:157 DNSRV CHILD: out of loop.. exiting normal > > Also I would like to ask.. I have the server setup, and I'm able to chat between >users on my server, I can even have someone from the internet login and I can chat >with them, as long as they are on my server.. However I heard it was possible to add >users from other servers and be able to chat with them, this doesn't work however.. >when I put in their JID, it just shows them as offline.. I'm not sure if anything has >to be setup in the server for this to work, I thought I saw someone say that it's >default.. Anyways this is on my home network, and I am running NAT on a Cisco 2514 >router. I'm not sure maybe I have to open more ports to it? currently I have 5222, >5269 and 7000 opened up to my Linux box.. any suggestions? > > Hope you can help.. Thanks, I greatly appreciate it, > > Ciscoswitch > Wayne Catterton > Network Engineer > Portland, OR > > PGP signature
Re: [JDEV] Jabber Client Design Tutorial
Michael - I have lots to say about your "guideline" and some of it has already been said by Temas + Julian (which I agree) with. I have struggled a lot lately on various projects that related to GUI design, and really what a lot of it comes down to is what a specific person likes best :) You obviously find the ICQ interface to an IM client easy to use and efficient, while some, like temas and I can't stand that kind of UI design. Others like AIM, and when I set out to design winjab for _myself_ I prefer'd something more akin to an email client. Much of my personal design stems from the way that I use windows and what I wanted. I could really care less what other people think of it and am continually astounded that so many people continue to download it. I think variety is the spice of life, and what I read from your document (which is potentially not what you were trying to say) is this: All jabber clients should look like ICQ. I think this is of course bogus, since i can't stand that specific UI. I applaud you for making a client that looks and feels like ICQ for the other folks that share your opinions and really like and love the ICQ UI. But IMO, there shouldn't be anything out there that even remotely "dictates" to the world what a jabber client should look like. For example, what about a javascript client? or a client thats embedded into a frame of a web page, or just a console app?? Those types of applications imply a very different type of client that you've layed out. Perhaps you should re-label your doc "Making a jabber client for a drop-in replacement for ICQ" ?? If you'd like me to go into more detail, please let me know... I'd be happy to share what thoughts/designs I disagree with in your doc, but I thought I'd fire this off as more of an "general feel about UI design on clients". Peter Millard - Original Message - From: "Michael Brown" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, September 24, 2001 2:51 AM Subject: Re: [JDEV] Jabber Client Design Tutorial > > Julian (x-virge) and I were discussing client design > > yesterday and I think you are a prime example of > > our discussion. There is a problem with Jabber, > > in general it's not everyones first IM client. > > Great! I've always wanted to be a prime example :-) > > It's true I guess, but it's not the only reason that people are turned off > Jabber. Really, the Jabber clients are very immature compared to the > clients for the commercial services. This is not meant as any disrespect to > the client authors - none of them have the resources of AOL or Microsoft > behind them, but this doesn't matter to the end user. To convince them to > switch services, the clients have to be at least 90% as good as the one they > are switching from. > > Also, the argument about switching from one of the proprietary services also > applies to switching between Jabber clients, so it would be nice to have > some sort of consistency between them if possible. > > > Users have generally been on another large network (AIM, ICQ, > > MSN, Yahoo!) before they come to Jabber. Despite their not > > liking the system (that's why they came to Jabber isn't it? ;-]) > > they tend to like their client, usually because they are comfortable > > with it. > > That's true in some cases. My reason for wanting to move from ICQ to Jabber > is more political than dissatisfaction with ICQ in the first place. I would > prefer that Jabber would become a system that attracts users by what it has > to offer, rather than just waiting for people to get sick of their existing > system. > > > If i had to guess, by reading your doc (which I did), > > you come from ICQ. > > If you had read my doc there should be no guessing involved. I am clearly > biased toward the ICQ interface as I have said since it is the one I have > used the longest (as it was the first one available), but that is not to say > that I have never used any other products. I use Lotus Sametime all day at > work, and have MSN installed. At the moment I am using Go Messenger as my > Jabber client, and have used JabberIM quite a lot. > > > Now I say this with absolutely no direction to you, but I find > > ICQ's UI absolutely atrocious, even AIM's is pretty wicked, > > so is Yahoo!, MSN is partially acceptable, but has many > > disparities. I say all that from a purely UI centric view. > > I was hoping for something a bit more substantial I have to admit. Saying > "xyz is atrocious" is not really productive, unless you can back up your > opinion with examples, and better options. ICQ's interface is a bit > confusing for a first time user, I have to admit, but for power users it is > great. AIM and MSN are much more basic clients, since their services lack > many of the features that ICQ and Jabber offer - such as offline messages - > but there are things that we can and should learn from them. > > > The idea of a doc to help get people rolling > > beyond the protocol is a great
Re: [JDEV] Jabber Client Design Tutorial
I think it's great that someone is paying attention to UI design, but I doubt that this document is going to be too useful. My impression is that developers who really care about good UI will tend to already know the things you're pointing out (they will steal ideas from the commercial clients, or actually do user testing, or think creatively about how to solve UI problems), while the majority(?) of developers for whom UI is an unpleasant chore will simply hack together something ugly that does the job. (At the risk of starting a flame war, in my experience nearly all Unix programmers tend to fall into the latter category.) No design document like yours will really reach the people who don't care about UI.
Some detailed points:
* You make the point that the client should integrate into the operating system's GUI, but then you show Mac-style flippy triangles for the group show/hide controls on a Windows client. For it to be Windows-like it should use the boxed "+" and "-" things that the generic Windows tree view uses.
* Your list of status states in Jabber is wrong. The default is called "Available", not "None". There is no "N/A", instead you mean "XA" ("extended away", and I have yet to see any coherent description of how this differs from regular "away".) Also, "invisible" is not currently supported by the Jabber server; if you manually set your presence to "unavailable" you stop receiving presence or messages. There's also an implicit "unknown" state for people whose presence you don't have a subscription to (presumably because they haven't approved your request yet.)
* You don't mention one issue that bugs me about current Jabber clients. The Jabber "resource name" is associated with a particular login. The best usage of this is to identify the location of the client, i.e. "work" or "laptop" or "home". For a non-PC client the type might be useful, like "cellphone" or "T900 pager". However, whenever I look at my buddy list it seems like most of the clients (gabber, winjab, etc.) just use the name of the client as the resource name. This is fairly useless -- usually I don't care what brand of desktop client they use. It is often useful to know whether they're at home, at work, in a cafe, whatever. IMHO the client, when first run, should ask the user to enter a resource name, and it should store that as a persistent preference. This type-in field should not default to the brand name of the client; it should be blank to encourage the user to type something meaningful.
* A related issue is how resources should be displayed in a client. If someone's online at two locations do they show up as two people, or as one person with two possible recipient addresses, or? Likewise, if someone has two known JIDs should they show up as separate people in the list or be coalesced into one?
* You might think about how the coming support for 'avatars' (pictures of users) can be integrated into Jabber user interfaces. Where should these be displayed? At what size? How do you configure yours? You want to give people a range of choices. A compact buddy list(tm) is efficient, but makes photos illegible. 64x64 photos look real pretty but take up a lot of room.
In general I think your comments are useful, but they're not pushing the envelope. They merely reflect the current 'best' practices of commercial IM clients, which IMHO all suck. No one has really thought through the issues and tried to do something better; they're all just repeating AOL's and ICQ's mistakes.
--Jens
Re: [JDEV] Jabber Client Design Tutorial
On Mon, Sep 24, 2001 at 10:27:57AM -0700, Jens Alfke wrote: > ugly that does the job. (At the risk of starting a flame war, in my > experience nearly all Unix programmers tend to fall into the latter > category.) No design document like yours will really reach the people Don't worry, I'm not going to flame - I agree with what you're saying, but it's important to say why they (I suppose I should use the word 'we') build clients that appear ugly to a lot of people - I for one *hate* having to point and click and follow cascading menus and have my screen cluttered by silly icons. I much prefer to control an app with my main input device - my keyboard - by a combination of keystrokes or whatever. I'm not saying this to be obtuse - it's the truth (and why I use mutt exclusively and still use sjabber on many conferences) and any UI design that excludes this point of view runs the risk of missing something fundamental. The group of people who feel most at home with a Unix command line and all the tools that such an environment comes with (including the ones with these 'ugly' UIs) may be a minority, but it's a damn huge minority. dj ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
Re: [JDEV] Jabber Client Design Tutorial
Hi. I find your GUI example interesting in many ways. I especially like your focus on keeping the client small and unobtrusive. What surprises me is that not you or anyone in the entire software world has tried to implement Jef Raskin's "Humane Interface". It is by far the most clever interface I've encountered. I'll present ideas for a jabber client based on Raskin's ideas as fast I get time to write it. If you haven't read his book I recommend it. It will completely change the way you look at interfaces. No, I'm not kidding. Raskin is the guy who designed the Macintosh and he seems to be the only person who has developed his interface ideas since the Macintosh was released. http://www.amazon.com/exec/obidos/ASIN/0201379376/qid=1001360936/sr=2-1/ref=sr_8_3_1/104-2763255-8995956 Here's something similar he wrote for Wired 1993. It's called "Down With GUIs": http://www.wired.com/wired/archive/1.06/1.6_guis_pr.html Rikard _ Do You Yahoo!? [EMAIL PROTECTED] - skaffa en gratis mailadress på http://mail.yahoo.se ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
Re: [JDEV] Jabber Client Design Tutorial
DJ, >Don't worry, I'm not going to flame - I agree with what you're >saying, but it's important to say why they (I suppose I should >use the word 'we') build clients that appear ugly to a lot of >people - I for one *hate* having to point and click and follow >cascading menus and have my screen cluttered by silly icons. >I much prefer to control an app with my main input device - my >keyboard - by a combination of keystrokes or whatever. How is this different from 'hotkeys'(like Alt <- for back on a browser, or Ctl-c to cut) that most(?) applications come with? >I'm not saying this to be obtuse - it's the truth (and why I use >mutt exclusively and still use sjabber on many conferences) and >any UI design that excludes this point of view runs the risk of >missing something fundamental. > >The group of people who feel most at home with a Unix command line >and all the tools that such an environment comes with (including >the ones with these 'ugly' UIs) may be a minority, but it's a damn >huge minority. However, what you raise here, is the bigger point of flexibility. Allowing 2/3/.. different ways to do the same thing may seem to be a bit of an overkill to most app developers and GUI designers, but it could well be the criteria some end users use to say Yay or Nay to their client. Also, most users, given the option of say, either pointing and clicking or using hotkeys, will soon start using the one they prefer and are used to. But, this doesn't mean the client shdn't give them the choice to do that. Regards, Ragavan _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
Re: [JDEV] Jabber Client Design Tutorial
On Monday, September 24, 2001, at 01:00 PM, Rikard Linde wrote: [Jef] Raskin is the guy who designed the Macintosh This is way, way off-topic, but Raskin did not design the Macintosh. He was the one who originally proposed and championed building a small, all-in-one, easy-to-use "appliance" computer with a GUI, and he gave it its name. But he left Apple in '81 or '82, years before the Mac shipped, and he didn't play much of a role in the actual engineering or HI design of the Mac product. I haven't read Raskin's book, but most of the other things I've read by him give me the impression he's a rather embittered guy with a lot of ideas that I, frankly, consider pretty wacko. If I'm going to read manifestoes by user-interface cranks, I'll take Ted Nelson any day -- his "Computer Lib / Dream Machines" totally changed my life in 1979. Jens
Re: [JDEV] Jabber Client Design Tutorial
> >I much prefer to control an app with my main input device - my > >keyboard - by a combination of keystrokes or whatever. > > How is this different from 'hotkeys'(like Alt <- for back on a browser, or > Ctl-c to cut) that most(?) applications come with? The difference is that command-line clients have no graphical interface: they are purely keystroke-driven. Think vi. Peter P.S. to DJ -- I still think pine > mutt. :P ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
Re: Re: [JDEV] Non english messages solution?
Jabberd use expat parser which uses UTF8 . UTF8 can convert unicode easily, and all you need to do is convert unicode to your native encoding,I think you use early windows 95 platform which not support unicode , but your native encoding may be GBK not gb2312 exactly, you can find a code table named cp936.txt for GBK and cp950 for BIG5 from http://www.unicode.org/pub .I am not sure for exact directory, but you can find it. A more reason solution you can what is your native encoding and convert to it in your code. a few days ago , I wrote some functions GBK2UNICODE and UNICODE 2GBK, I do it query the code table but I can not find a good algorithm, if you get pls. tell me. If you have further question , feel free to mail me. > Alex She > Yes, I have tried that. > I sent a message from gb2312 encoding client to big5 encoding > client.The original byte stream is "d4acd6ceb9fa".But I got "b04baa763f" > from jabberCOM in big5 encoding client.It is wrong. How can I convert it > to native? > Thanks. > > >convert to local, > >1cn.com>:> Hi, > >> > >>Is there any Non english messages solution? My Friend and I use > >> winjabber to chat.But we use different encoding. One is > >> gb2312, the other is big5.we can not see the messages each other. > >>Thanks for any info. > >> > >> Regards, > >> > >> - Lg > >> > >> 2001-9-21 21:38:08 > >> > >> -- > >> Gang Liu / Vista Team / ShenZhen City / China > >> Email: [EMAIL PROTECTED] & [EMAIL PROTECTED] > >> Phone: +86 13923425035 > >> ICQ: 70670666 > >> Web: Coming > >> > >> ___ > >> jdev mailing list > >> [EMAIL PROTECTED] > >> http://mailman.jabber.org/listinfo/jdev > >> > > > > > >- > >This mail sent through IMP: mail.wizdomtech.com > >___ > >jdev mailing list > >[EMAIL PROTECTED] > >http://mailman.jabber.org/listinfo/jdev > > = = = = = = = = = = = = = = = = = = = = > > > > ___ > jdev mailing list > [EMAIL PROTECTED] > http://mailman.jabber.org/listinfo/jdev > - This mail sent through IMP: mail.wizdomtech.com ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
Re: [JDEV] Jabber Client Design Tutorial
First off, I don't believe in the idea of having similar-looking Jabber
clients. It would be nice to have a defacto client for each OS which
looks and acts similarly, but beyond that, I want creativity to shine. I
want to see different approaches at IM, not 20 VB clients for windows
which look and act *exactly the same* - what's the point in that?
Replies within.
Jens Alfke wrote:
> * Your list of status states in Jabber is wrong. The default is called
> "Available", not "None". There is no "N/A", instead you mean "XA"
> ("extended away", and I have yet to see any coherent description of how
> this differs from regular "away".) Also, "invisible" is not currently
> supported by the Jabber server; if you manually set your presence to
> "unavailable" you stop receiving presence or messages. There's also an
> implicit "unknown" state for people whose presence you don't have a
> subscription to (presumably because they haven't approved your request
> yet.)
>
Actually, latest jabberd does support invisible.
> * You don't mention one issue that bugs me about current Jabber clients.
> The Jabber "resource name" is associated with a particular login. The
> best usage of this is to identify the location of the client, i.e.
> "work" or "laptop" or "home". For a non-PC client the type might be
> useful, like "cellphone" or "T900 pager". However, whenever I look at my
> buddy list it seems like most of the clients (gabber, winjab, etc.) just
> use the name of the client as the resource name. This is fairly useless
> -- usually I don't care what brand of desktop client they use. It /is/
> often useful to know whether they're at home, at work, in a cafe,
> whatever. IMHO the client, when first run, should ask the user to enter
> a resource name, and it should store that as a persistent preference.
> This type-in field should not default to the brand name of the client;
> it should be blank to encourage the user to type something meaningful.
>
According to all statistics I can get ahold of and from various small user tests -
people do *not* easily understand the concept of a resource unless they specifically
intend to be logged in multiple times - and *most* users never use that feature of
Jabber. Therefore, 'Gabber' is the default resource to reduce confusion - if the user
doesn't understand it, they don't have to become frustrated trying to figure out what
is going on. They can live happily without know what a resource is. That's the entire
point of the MacOS HI guideline which states that options are nice, but you *must*
*have* *good* *defaults*.
If in the future the majority of users need to understand the concept of
a resource, I'll gladly remove the default, but the point of UI is to
reduce the amount of information a user must learn and retain.
I need sleep
Julian
--
email: [EMAIL PROTECTED]
jabber:[EMAIL PROTECTED]
___
jdev mailing list
[EMAIL PROTECTED]
http://mailman.jabber.org/listinfo/jdev
Re: [JDEV] Jabber Client Design Tutorial
On 24/09/2001 at 9:57 PM Julian Missig wrote: >First off, I don't believe in the idea of having similar-looking Jabber >clients. It would be nice to have a defacto client for each OS which >looks and acts similarly, but beyond that, I want creativity to shine. I >want to see different approaches at IM, not 20 VB clients for windows >which look and act *exactly the same* - what's the point in that? agree 100% >According to all statistics I can get ahold of and from various small user >tests - people do *not* easily understand the concept of a resource unless >they specifically intend to be logged in multiple times - and *most* users >never use that feature of Jabber. Therefore, 'Gabber' is the default >resource to reduce confusion - if the user doesn't understand it, they >don't have to become frustrated trying to figure out what is going on. >They can live happily without know what a resource is. That's the entire >point of the MacOS HI guideline which states that options are nice, but >you *must* *have* *good* *defaults*. But, even if a user doesn't intent to log on multiple times simultaneously, a description of where they are currently logged in from is still useful. Surely it is clear to a user that they are entering a description of what computer they are logging in from and when they look at another user in their roster they can see where they are logged in from?... even if they don't understand the concept of resources and how they interact. If I gave a Jabber client to an inexperienced Jabber user and it said enter a description of where you are connecting from, they would enter "Home" or "Laptop" or something and then they would never have to worry about it again. Julian (the other one) ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
Re: [JDEV] Jabber Client Design Tutorial
Julian Fitzell wrote: > On 24/09/2001 at 9:57 PM Julian Missig wrote: > > But, even if a user doesn't intent to log on multiple times simultaneously, a >description of where they are currently logged in from is still useful. Surely it is >clear to a user that they are entering a description of what computer they are >logging in from and when they look at another user in their roster they can see where >they are logged in from?... even if they don't understand the concept of resources >and how they interact. > > If I gave a Jabber client to an inexperienced Jabber user and it said enter a >description of where you are connecting from, they would enter "Home" or "Laptop" or >something and then they would never have to worry about it again. > > Julian (the other one) > Well, in the few tests I did, whenever I asked for something like that, they would turn around and ask me if I meant their country or their city or what. However, this was most likely an issue of wording which deserves further investigation. Asking the user to enter a description of where they're connecting from doesn't solve very much since they still don't get a complete understanding of resources. Also keep in mind that nowhere does it state that a resource must be a physical location. If I'm running multiple clients on one machine, I think it would be useful to know which two clients they are using. What happens if the user sets up, say, sjabber and Gabber on their machine, and both clients follow this question format? The user might enter "Home" into both clients - hey, they're both at the same location, why would you want to give them different locations, it's the same machine, even! Then the user would not understand why they cannot connect with both at the same time, and you have to force feed them the description of a resource, and maybe they'll get it - maybe they won't and just go on thinking you can only connect once with one Jabber account. Not to mention that fact that I'm not particularly a fan of always using a resource to describe location. It describes your session in a unique way from the others. In the future, multiple Jabber sessions from one physical location will become more and more common. Julian -- email: [EMAIL PROTECTED] jabber:[EMAIL PROTECTED] ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
RE: [JDEV] Jabber Client Design Tutorial
I think the concept of this document is fantastic and extremely important.
Whilst a lot of us involved in Jabber might not be particularly interested
in UI's, it is probably more important to Jabber's success in the short term
than the server. I say this only because it's very frustrating and
disappointing to see supposedly "informed" tech writers slag off Jabber
because of a client app they downloaded and couldn't figure. TechTV, gave
jabber a 1 star. They didn't even mention the server, cause to the end user
it doesn't mean anything.
No need to preach here, cause we're all believers. But if we can start to
foster some UI "what ifs" discussions (maybe here, maybe not) and start to
think from the end users point of view, whether they be students, parents,
newbie's, business, etc, then when asshole's like TechTV do a review they
will see a number of clients that get their little brains thinking. Sorry,
but I couldn't believe it when I saw Jabber get a one star and other useless
crap out there get 5's.
I'm going to start working on some designs for clients to get some comments
from everyone. Anything that gets us thinking about the end user and how
they use Jabber is a good thing.
Keep up the great work guys.
cheers,
Darren
-Original Message-
From: Julian Missig [mailto:[EMAIL PROTECTED]]
Sent: Monday, September 24, 2001 6:57 PM
To: [EMAIL PROTECTED]
Subject: Re: [JDEV] Jabber Client Design Tutorial
First off, I don't believe in the idea of having similar-looking Jabber
clients. It would be nice to have a defacto client for each OS which
looks and acts similarly, but beyond that, I want creativity to shine. I
want to see different approaches at IM, not 20 VB clients for windows
which look and act *exactly the same* - what's the point in that?
Replies within.
Jens Alfke wrote:
> * Your list of status states in Jabber is wrong. The default is called
> "Available", not "None". There is no "N/A", instead you mean "XA"
> ("extended away", and I have yet to see any coherent description of how
> this differs from regular "away".) Also, "invisible" is not currently
> supported by the Jabber server; if you manually set your presence to
> "unavailable" you stop receiving presence or messages. There's also an
> implicit "unknown" state for people whose presence you don't have a
> subscription to (presumably because they haven't approved your request
> yet.)
>
Actually, latest jabberd does support invisible.
> * You don't mention one issue that bugs me about current Jabber clients.
> The Jabber "resource name" is associated with a particular login. The
> best usage of this is to identify the location of the client, i.e.
> "work" or "laptop" or "home". For a non-PC client the type might be
> useful, like "cellphone" or "T900 pager". However, whenever I look at my
> buddy list it seems like most of the clients (gabber, winjab, etc.) just
> use the name of the client as the resource name. This is fairly useless
> -- usually I don't care what brand of desktop client they use. It /is/
> often useful to know whether they're at home, at work, in a cafe,
> whatever. IMHO the client, when first run, should ask the user to enter
> a resource name, and it should store that as a persistent preference.
> This type-in field should not default to the brand name of the client;
> it should be blank to encourage the user to type something meaningful.
>
According to all statistics I can get ahold of and from various small user
tests - people do *not* easily understand the concept of a resource unless
they specifically intend to be logged in multiple times - and *most* users
never use that feature of Jabber. Therefore, 'Gabber' is the default
resource to reduce confusion - if the user doesn't understand it, they don't
have to become frustrated trying to figure out what is going on. They can
live happily without know what a resource is. That's the entire point of the
MacOS HI guideline which states that options are nice, but you *must* *have*
*good* *defaults*.
If in the future the majority of users need to understand the concept of
a resource, I'll gladly remove the default, but the point of UI is to
reduce the amount of information a user must learn and retain.
I need sleep
Julian
--
email: [EMAIL PROTECTED]
jabber:[EMAIL PROTECTED]
___
jdev mailing list
[EMAIL PROTECTED]
http://mailman.jabber.org/listinfo/jdev
___
jdev mailing list
[EMAIL PROTECTED]
http://mailman.jabber.org/listinfo/jdev
Re: [JDEV] Jabber Client Design Tutorial
Oh, yes, I agree. We still are lacking a very good windows client. We definitely need some UI designers (who are aware of the Windows UI guidelines, by the way, and try to make the app follow them) to work with some programmers to get a really good windows client out there. But that's completely different from having an official Jabber specification stating that all clients must be ICQ. Even an informal one, I don't agree with. All it takes is one really good Jabber client, then the rest are free to do what they want, we can all point toward the one we like. Julian -- email: [EMAIL PROTECTED] jabber:[EMAIL PROTECTED] Darren McVean wrote: > I think the concept of this document is fantastic and extremely important. > Whilst a lot of us involved in Jabber might not be particularly interested > in UI's, it is probably more important to Jabber's success in the short term > than the server. I say this only because it's very frustrating and > disappointing to see supposedly "informed" tech writers slag off Jabber > because of a client app they downloaded and couldn't figure. TechTV, gave > jabber a 1 star. They didn't even mention the server, cause to the end user > it doesn't mean anything. > > No need to preach here, cause we're all believers. But if we can start to > foster some UI "what ifs" discussions (maybe here, maybe not) and start to > think from the end users point of view, whether they be students, parents, > newbie's, business, etc, then when asshole's like TechTV do a review they > will see a number of clients that get their little brains thinking. Sorry, > but I couldn't believe it when I saw Jabber get a one star and other useless > crap out there get 5's. > > I'm going to start working on some designs for clients to get some comments > from everyone. Anything that gets us thinking about the end user and how > they use Jabber is a good thing. > > Keep up the great work guys. > > cheers, > Darren > ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
Re: Re: Re: [JDEV] Non english messages solution?
Alex She Jabberd use expat parser which uses UTF8 . UTF8 can convert unicode easily, and >all you need to do is convert unicode to your native encoding,I think you use >early windows 95 platform which not support unicode , but your native encoding >may be GBK not gb2312 exactly, you can find a code table named cp936.txt for >GBK and cp950 for BIG5 from http://www.unicode.org/pub .I am not sure for exact >directory, but you can find it. Yes, you are right.The jabberd use UTF8 on the fly.But How can I Convert it to native code? When I recv the message, I got the UTF8 byte stream. I can easily convert it to unicode. Now I do not know which encoding I should use to convert to native. I can not get charset of the message from jabber protocol. -- UTF8 byte stream -> jabberd -- UTF8 byte stream --> unicode GBK or BIG5 ? -> native? Thanks for u info. >A more reason solution you can what is your native encoding and convert to it >in your code. a few days ago , I wrote some functions GBK2UNICODE and UNICODE >2GBK, I do it query the code table but I can not find a good algorithm, if you >get pls. tell me. In client side, I am using VC++ and JabberCOM. In server side, I use java. I can easily get unicode. >If you have further question , feel free to mail me. >> Alex She > >> Yes, I have tried that. >> I sent a message from gb2312 encoding client to big5 encoding >> client.The original byte stream is "d4acd6ceb9fa".But I got "b04baa763f" >> from jabberCOM in big5 encoding client.It is wrong. How can I convert it >> to native? >> Thanks. >> >> >convert to local, >> >1cn.com>:> Hi, >> >> >> >> Is there any Non english messages solution? My Friend and I use >> >> winjabber to chat.But we use different encoding. One is >> >> gb2312, the other is big5.we can not see the messages each other. >> >> Thanks for any info. >> >> >> >> Regards, >> >> >> >> - Lg >> >> >> >> 2001-9-21 21:38:08 >> >> >> >> -- >> >> Gang Liu / Vista Team / ShenZhen City / China >> >> Email: [EMAIL PROTECTED] & [EMAIL PROTECTED] >> >> Phone: +86 13923425035 >> >> ICQ: 70670666 >> >> Web: Coming >> >> >> >> ___ >> >> jdev mailing list >> >> [EMAIL PROTECTED] >> >> http://mailman.jabber.org/listinfo/jdev >> >> >> > >> > >> >- >> >This mail sent through IMP: mail.wizdomtech.com >> >___ >> >jdev mailing list >> >[EMAIL PROTECTED] >> >http://mailman.jabber.org/listinfo/jdev >> >> = = = = = = = = = = = = = = = = = = = = >> >> >> >> ___ >> jdev mailing list >> [EMAIL PROTECTED] >> http://mailman.jabber.org/listinfo/jdev >> > > >- >This mail sent through IMP: mail.wizdomtech.com >___ >jdev mailing list >[EMAIL PROTECTED] >http://mailman.jabber.org/listinfo/jdev = = = = = = = = = = = = = = = = = = = = Gang Liu [EMAIL PROTECTED] 2001-09-25 ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
Re: [JDEV] Jabber Client Design Tutorial
On 24/09/2001 at 10:36 PM Julian Missig wrote: >Well, in the few tests I did, whenever I asked for something like that, >they would turn around and ask me if I meant their country or their city >or what. However, this was most likely an issue of wording which deserves >further investigation. Asking the user to enter a description of where >they're connecting from doesn't solve very much since they still don't get >a complete understanding of resources. > >Also keep in mind that nowhere does it state that a resource must be a >physical location. If I'm running multiple clients on one machine, I >think it would be useful to know which two clients they are using. > >What happens if the user sets up, say, sjabber and Gabber on their >machine, and both clients follow this question format? The user might >enter "Home" into both clients - hey, they're both at the same location, >why would you want to give them different locations, it's the same >machine, even! Then the user would not understand why they cannot >connect with both at the same time, and you have to force feed them the >description of a resource, and maybe they'll get it - maybe they won't >and just go on thinking you can only connect once with one Jabber account. > >Not to mention that fact that I'm not particularly a fan of always using >a resource to describe location. It describes your session in a unique >way from the others. In the future, multiple Jabber sessions from one >physical location will become more and more common. Well, this is all true except that I suspect most people who can't grasp the idea of a unique identifier are not very likely to be running multiple clients at once. Now I can see that in the near future they might be running multiple apps that are Jabber enabled... maybe these apps could adopt the convention of asking for a location and prepending it with the app name: "Gabber_Home"?? I do this sometimes myself because my friends know what features I have available based on what client I'm running. Obviously this is a default that the user can override with any resource they want but it would be a more meaningful and unique resource. Also, isn't a user far more likely to try to run the *same* client from two locations than two clients on the same machine? In this scenario, they still won't be able to log in and won't know why... hmm, actually, I guess the newer connection always bumps the older one... but if their first client automatically reconnects. Julian ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
Re: [JDEV] Jabber Client Design Tutorial
>> But, even if a user doesn't intent to log on multiple times simultaneously, a
>description
of where they are currently logged in from is still useful. Surely it is clear to a
user that
they are entering a description of what computer they are logging in from and when
they look at another user in their roster they can see where they are logged in
from?...
even if they don't understand the concept of resources and how they interact.
>>
>> If I gave a Jabber client to an inexperienced Jabber user and it said enter a
description of where you are connecting from, they would enter "Home" or "Laptop" or
something and then they would never have to worry about it again.
>>
>> Julian (the other one)
>>
>
>
>Well, in the few tests I did, whenever I asked for something like that, they would
>turn
around and ask me if I meant their country or their city or what. However, this was
most
likely an issue of wording which deserves further investigation. Asking the user to
enter a
description of where they're connecting from doesn't solve very much since they still
don't get a complete understanding of resources.
>
>
One way around all this would be a set of suggestions for reasonable resource strings.
WinJabber does this with a pulldown. I have not tried entering my own in there as
"Laptop" just about describes what I am working with at the time.
If you are running a logging client, to capture your IM's that are not cached
elsewhere,
'Logging" seems reasonable to me. If it is important to you that people know whether
you are at work (work), home (home), at a convention (peer.networking), or sitting in
the
middle of the lake pulling in walleyes (occupational.rehabilitation), you could select
or
create an appropriate resource for that. You could even have a resource that would
capture IMs and forward them to your text pager or digital cell phone with a resource
name "pager".
While a well written application should be intuitive, and not require the user to
spend an
inordinate amount of time looking up explanations for what is expected in different
fields,
sometimes it makes sense to provide redily available help or suggestions for each
field
as well.
For clients that perform services for you, either as avatars, such as a jabber
callendar
client which could im a pager client to remind either yourself or a peer that it was
time
for a meeting, or to pick up something for your aniversary before you got home, or a
pager type client that is inbound only, it would make sense to have pre-defined
resources that other clients would recognize, and treat appropriately.
In any case, a first time user is not going to know intuitively what some of the more
arcane resource names mean. If they are using WinJabber, how likely is it that they
will
recognize that the resource "Marvin" could be an indication that the user of the
"Marvin"
jabber app (A fully skinable Jabber client for Windows written in Euphoria) decided
not
to enter a custom resource {presuming that 'Marvin" were the default resorce for that
app, I don't know.} They might just think the user is having a particularly bad day
with
pains running up and down their left arm, and mistakenly try to cheer the user up.
Just some ideas.
Others include using 'services' numbers or names for resources if they are specific to
some service. 25:smtp for a mail service, 79:finger for a response about the user,
(other
than a vcard) 80:http for the users home page, or hot link of the day, or whatever.,
444:snpp for paging, 533:netwall for emergency broadcasts 555:whoami for a response
based upon pulling down the vcard of the person contacting that resource, and the
like.
Resources for services available in clients could be shown either by service name, or
number, and user clients could be designed to ignore those resources unless the user
is in
some advanced mode. I would suspect that properly written service clients would
discard messages that were improperly formated, or log them to some sort of a syslog
resource some place.
A user "manager" client could be created as part of a user client, and it would look
for
resources for users that have agreed to notification both ways, and depending upon
each user's paranoia index can either add those contacts to the local facilities, or
make
available similar resources to the other user. I think it could work something like a
shared
callendar where some events are not available to other users of the shared callendar,
some are only "I am unavailable for this block of time" events (my peers do not need
to
know that I have to take my cat into the vet, but they probably shouldn't attempt to
schedule a meeting for me while I am there.) And others are fully shared, "I will be
involved in the annual review of all of your budgets today, do you really want me
upset?"
Likewise I may want my pager available for co-workers and supervisors, but not for the
jokers I quaf a fe
Re: Re: Re: [JDEV] Non english messages solution?
Mr Gang Liu <[EMAIL PROTECTED]>: why You use java as sever side ? I can not understand you. tell me if you can. if no touch with jabber server, it can handle all encode, in VC++, you can convert from ... and to ... so easily. good luck! - This mail sent through IMP: mail.wizdomtech.com ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
Re: [JDEV] Jabber Client Design Tutorial
I've been reading this list for about a month while slowly writing a 'Jabber Client'. I do believe UI is important, but my client doesn't have one yet. Actually my client is a module for a webserver called AOLserver. I am late coming to Jabber. I first found out about it from an article in _Linux Magazine_, August 2001! It was enough for me it seriously consider the usefulness of this technology. I don't need to sell that here, but what I would like to sell is the usefulness of exposing the jabber packets to a programming environment that is easy to use, and that would support module like applications. What I have done so far is to create a C module for AOLserver that uses the libxode and libjabber api. This api is exposed to the scripting environment of AOLserver which is TCL. The individual xmlnodes which represent the jabber packets are passed into the scripting environment as well. From this point, the programmer is free to handle the packets however they wish. I'm sure this is similar to the perl api, but there are differences. AOLserver is a multi-threaded, general purpose server. It has a complete database api, it is a high performance webserver. Although Apache is a very good webserver, Jabber requires a continuous connection and shared memory to be effective. My initial ideas of using jabber were merely as a way of delivering messages from a website. I quickly realized that writing a bot was not that difficult with this client. Today, while reading this thread, I realized that AOLserver could serve as a nice user client, not just a client for a webserver. My reasoning was simple: AOLserver has too large of a footprint to directly serve many users, but it is small in relation to most GUI software. The client software could be installed on a user's personal machine, or on a firewall. The user would then connect to the client using a web browser. Since AOLserver is a general purpose server, there is even the possibility of connecting a display client, instead of a browser. Obviously it would be realtively easy to integrate any oob needs into this type of setup. I have a simple three function bot that answers to [EMAIL PROTECTED]/ws. It is hardly an ideal bot, but it demonstrates that you can easily add module like functions in a simple way. I hope this was not too off topic, but the UI is an extremely labor intensive process. If significant functions can be added without the constant need to worry about the UI programming, it might speed up use of Jabber as a technology. --Tom Jackson ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
Re: [JDEV] Non english messages solution?
On Monday, September 24, 2001, at 07:50 PM, Gang Liu wrote: > When I recv the message, I got the UTF8 byte stream. I can easily > convert it to unicode. Now I do not > know which encoding I should use to convert to native. I can not get > charset of the message from jabber protocol. Jabber messages don't have charsets. They don't need them, they're Unicode. What you need to do is convert the Unicode data directly into your native character set, whatever that is. Mac OS includes support for these encoding translations, and so do Windows NT 4, 98 and later. Dunno about Unix. I suspect that you actually have an issue with the client library you're using (JabberCOM), not with the Jabber protocol itself. If you need help using JabberCOM or Windows Unicode translation utilities, this probably isn't the best list to ask those questions on... --Jens ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
Re: [JDEV] Jabber Client Design Tutorial
On Monday, September 24, 2001, at 07:25 PM, Julian Fitzell wrote: > If I gave a Jabber client to an inexperienced Jabber user and it said > enter a description of where you are connecting from, they would enter > "Home" or "Laptop" or something and then they would never have to worry > about it again. That's what my client does. It describes the resource name in about one sentence and gives "Home", "PowerBook" and "Naomi's Office" as typical examples. Most people testing it manage to figure this out pretty well. Also, once people are actually using the client and see the resource names next to their buddies' names, they get the point and sometimes clean up their own resource name if they put in something awkward originally. --Jens ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
Re: Re: Re: Re: [JDEV] Non english messages solution?
Alex She Mr Gang Liu <[EMAIL PROTECTED]>: >why You use java as sever side ? I can not understand you. tell me if you can. I use java to write my own xdb module. The jabberd is from jabber.org. >if no touch with jabber server, it can handle all encode, in VC++, you can >convert from ... and to ... so easily. I do not change anything in jabberd. I think that u do not understand my question. U can try it yourself.Send a GBK encoding message to BIG5 client. Thanks. >good luck! > > > >- >This mail sent through IMP: mail.wizdomtech.com >___ >jdev mailing list >[EMAIL PROTECTED] >http://mailman.jabber.org/listinfo/jdev = = = = = = = = = = = = = = = = = = = = Ö Àñ£¡ Gang Liu [EMAIL PROTECTED] 2001-09-25 ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
Re: [JDEV] Jabber Client Design Tutorial
On Mon, Sep 24, 2001 at 01:36:01PM -0700, Ragavan S wrote: > > How is this different from 'hotkeys'(like Alt <- for back on a browser, or > Ctl-c to cut) that most(?) applications come with? Because there's no overhead (screen real-estate or otherwise) that's to be lost to 'useless' menus and so on. >From my (perhaps limited) windows experience, there are more GUI apps that do the hotkey stuff badly than well. I guess I'm thinking of the mainframe environments I grew up with - ISPF, SDSF, and so on. Even today, I haven't seen an environment, graphical or no, to beat them. And they were 80x25 text format too. A fantastic combination of hotkeys and small commands entered on a command line. > hotkeys, will soon start using the one they prefer and are used to. But, > this doesn't mean the client shdn't give them the choice to do that. Absolutely. Flexibility is great. But not at any price. dj 'old-git' ISPF editor fan ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
Re: [JDEV] Jabber Client Design Tutorial
On Mon, Sep 24, 2001 at 08:23:28PM -0700, Tom Jackson wrote: > I hope this was not too off topic, but the UI is an extremely labor > intensive process. If significant functions can be added without the > constant need to worry about the UI programming, it might speed up use > of Jabber as a technology. Indeed. I know this thread was about (G)UI design, but I'd like to echo what Tom says; I guess many of you that frequent the jdev room will know my feelings about GUIs and such ;-) - I'd just like to point out that 90% of the stuff I do with Jabber doesn't involve a (G)UI at all. I *know* Jabber's primary face with the media is still Open IM, but that doesn't mean it's the only face. dj (qmacro) p.s. cheers for stpeter for introducing Tom to Jabber with his great article :-) ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
Re: Re: Re: Re: [JDEV] Non english messages solution?
> >Mr Gang Liu <[EMAIL PROTECTED]>: > >why You use java as sever side ? I can not understand you. tell me if > you can. > I use java to write my own xdb module. The jabberd is from > jabber.org. I work hard to write xdb to oracle , I use xdb_sql and prco c language, and a long way to go for me. I need detail about java xdb module. > I do not change anything in jabberd. I think that u do not > understand my question. > U can try it yourself.Send a GBK encoding message to BIG5 client. my im client can do this successfully. following is some clues. 1. jabber im not supprot point to point. A send a msg to b , is a send a msg to server, and server send it to b if he online, or store and forward. 2. any client send stream in UTF8, which has a direct bit map to unicode , so some one call UTF8 as unicode, exactly it is wrong, lookup UTF8 in search engine for more details. 3. for big5 http://www.unicode.org/Public/MAPPINGS/OBSOLETE/EASTASIA/OTHER/BIG5.TXT 4. for gbk http://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WINDOWS/CP936.TXT 5. gb2312 is a subset of GBK after some handle, and you use GBK not gb2312. All in one: if you convert incoming UTF8 stream to native charset, everything is done, BTW , what parser you use in client end? expat? if not , you may look at your client parser. goood luuck. - This mail sent through IMP: mail.wizdomtech.com ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
Re: [JDEV] Jabber Client Design Tutorial
> Oh, yes, I agree. We still are lacking a very good windows client. We > definitely need some UI designers (who are aware of the Windows UI > guidelines, by the way, and try to make the app follow them) to work > with some programmers to get a really good windows client out there. The best way to start this process is with users on this list sending their detailed likes and dislikes on various clients. Sending a message that a particular client 'sucks' does not help the process. Instead an explanation, on why a particular feature is not correctly implemented or there is a better way to achieve something in the User Interface is much more productive. BTW Michael, your document was very well written. I don't think there is ONE correct UI and diversity is something to be proud of. But I hope we can use this debate to find out how Jabber clients can exceed the other clients in terms of User Experience. Regards, Ashvil ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
