Menu
▾
▴
pidgin-devel — DO NOT USE. See https://pidgin.im/cgi-bin/mailman/listinfo/devel
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(27) |
Jul
(25) |
Aug
(21) |
Sep
(136) |
Oct
(123) |
Nov
(87) |
Dec
(110) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(87) |
Feb
(88) |
Mar
(81) |
Apr
(255) |
May
(73) |
Jun
(96) |
Jul
(131) |
Aug
(94) |
Sep
(148) |
Oct
(171) |
Nov
(166) |
Dec
(172) |
| 2004 |
Jan
(251) |
Feb
(140) |
Mar
(213) |
Apr
(298) |
May
(182) |
Jun
(185) |
Jul
(159) |
Aug
(376) |
Sep
(334) |
Oct
(256) |
Nov
(217) |
Dec
(189) |
| 2005 |
Jan
(186) |
Feb
(151) |
Mar
(199) |
Apr
(115) |
May
(203) |
Jun
(228) |
Jul
(116) |
Aug
(189) |
Sep
(136) |
Oct
(198) |
Nov
(249) |
Dec
(339) |
| 2006 |
Jan
(167) |
Feb
(185) |
Mar
(95) |
Apr
(133) |
May
(86) |
Jun
(156) |
Jul
(149) |
Aug
(170) |
Sep
(208) |
Oct
(151) |
Nov
(270) |
Dec
(148) |
| 2007 |
Jan
(240) |
Feb
(127) |
Mar
(150) |
Apr
(40) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Louis G. <lou...@be...> - 2002-11-17 03:23:53
|
I am running cvs gaim on my rh8 box under gnome and want to know how to login automatically. I use to be able to do this with gnome-1.4 and its panel applet. With the tray icon I have not found a way. Thanks |
|
From: Robert M. <rob...@de...> - 2002-11-17 00:46:56
|
On Wed, Nov 13, 2002 at 03:49:29PM -0800, Herman Bloggs wrote: > Update of /cvsroot/gaim/gaim/src > In directory usw-pr-cvs1:/tmp/cvs-serv14316 > > Modified Files: > away.c > Log Message: > Registering I'm back window with systray module AHHHHH! IT'S THE APPLET ALL OVER AGAIN! /me runs away screaming -Rob |
|
From: Felipe C. <al5...@ma...> - 2002-11-16 19:32:09
|
On Sat, Nov 16, 2002 at 11:40:11AM -0500, Ethan Blanton wrote: > The bullets you've outlined all seem very reasonable to me, with one > little clarification I'd like to make. > > > o When changing an alias the nick should be displayed in the dialog. > > It's fine if the nick is shown as a secondary data point somewhere, > but I think that the buddy's identity should be visible at this point. > Identities are guaranteed to be unique, nicks may not be. Sure, for example the alias buddy dialog should show this: Buddy: sh...@ho... Nick: shx Alias: me -- Felipe Contreras |
|
From: Ethan B. <ebl...@cs...> - 2002-11-16 16:42:48
|
Felipe Contreras spake unto us the following wisdom:
> I've been working on this nick autoupdate thing and this is the solution I
> purpose:
>=20
> nick =3D The remote nick, set by the server.
> alias =3D The local alias, set by the user.
The bullets you've outlined all seem very reasonable to me, with one
little clarification I'd like to make.
> o When changing an alias the nick should be displayed in the dialog.
It's fine if the nick is shown as a secondary data point somewhere,
but I think that the buddy's identity should be visible at this point.
Identities are guaranteed to be unique, nicks may not be.
> I've made a patch to implement all this and seems to work fine, I'll test
> it a while, and then upload to SF.
>=20
> Any comments? Could this be merged in the official code?
It would certainly stop a lot of crying. ;-)
Ethan
--=20
And if I claim to be a wise man / it surely means that I don't know.
-- Kansas, "Carry on Wayward Son"
|
|
From: Felipe C. <al5...@ma...> - 2002-11-16 08:38:38
|
Hi all, I've been working on this nick autoupdate thing and this is the solution I purpose: nick = The remote nick, set by the server. alias = The local alias, set by the user. o If the protocol sends nick updates, receive them and store them in a 'nick' field for each buddy which will only be udpated from the server. o The user will change the 'alias' of a buddy by hand always. o If there is an alias, the alias is displayed, if not and there is a nick then the nick is displayed, if not, then the buddy name. o Both aliases and nicks should be displayed in tooltips. o When changing an alias the nick should be displayed in the dialog. o What will be stored in the blist files will be the alias, the remote nick will not be stored on disk, only updated in memory while gaim is running. o For the people that don't use protocols that send nick updates there will be no difference. If they use protolcs that send nick updates but they have aliases for all their buddies then they will only see an extra field for their buddies in some places. I've made a patch to implement all this and seems to work fine, I'll test it a while, and then upload to SF. Any comments? Could this be merged in the official code? -- Felipe Contreras |
|
From: <lsc...@re...> - 2002-11-15 17:40:04
|
On Fri, Nov 15, 2002 at 12:31:33PM -0500, Evan Doughty wrote: > On Fri, 2002-11-15 at 10:56, Ethan Blanton wrote: > > (Bringing this back to gaim-devel, I hope you don't mind.) <snip> > Doesn't gaim-e work with Jabber anyway? I understand that not everyone > runs Gaim, but with the Windows client on the way and the problems with > OpenSSL, that may be the simple solution. :) gaim-e works across any gaim conversation. if you read the faq, you will notice that this is the (only) suggested method of secure im with gaim. gaim-e.sf.net for more information :-) luke -- -This email is made of 100% recycled electrons. |
|
From: Ethan B. <ebl...@cs...> - 2002-11-15 17:40:02
|
Evan Doughty spake unto us the following wisdom:
> Doesn't gaim-e work with Jabber anyway? I understand that not everyone
> runs Gaim, but with the Windows client on the way and the problems with
> OpenSSL, that may be the simple solution. :)
The high-order bit there is not that gaim is available for Windows,
but that the work being done on gaim-e is completely open and free for
reimplmentation in any client.
Gaim may be the only client so trivially extensible via plugins, that
I don't know... :-)
Ethan
--=20
And if I claim to be a wise man / it surely means that I don't know.
-- Kansas, "Carry on Wayward Son"
|
|
From: Luke S. <lsc...@gm...> - 2002-11-15 17:35:38
|
On Fri, Nov 15, 2002 at 10:56:02AM -0500, Ethan Blanton wrote: > (Bringing this back to gaim-devel, I hope you don't mind.) > > Scott spake unto us the following wisdom: > > The presence bar is a pull down menu allowing you to select > > different away 'types' (in gabber: "Available", "Free to Chat", > > "Away", "Extended Away", "Busy", and "Invisible"). In Gaim, the > > functionality of the button bar is all replicated elsewhere, and is > > wasted space, imo. Currently when you are 'away', you get a text > > dialog with your away message and a button saying 'I'm Back' which > > again imo, is annoying and can get lost amongst a myriad of > > windows. It would be more tidy to have the pulldown menu to select > > and see your 'presence' at a glance in the gaim window. > > Ahh. I agree that away-ness is rather complicated in gaim as things > stand right now; unfortunately, such a presence bar simply would not > work in gaim. It is perfectly reasonable (and common, even!) to have a presence bar can be implemented, there is a patch by derjohan that does this that will be evaluated after the move to gtk2 is complete. Further, a status menu, see patch by deryni, is also up for consideration at that time. we are looking to make the presence bar optional, and the menu there all the time. > different away states for different accounts (notice that you can > select an individual account from the menu when you choose to go > away). I personally also agree that buttons at the bottom of the > buddy list are mostly useless ... I use the preference item to turn > them off. > > > Has there been any talk about getting SSL support for Jabber? > > Yes, and it is not likely to happen soon or at all. There is an entry > in the FAQ about the security-related reasons (it isn't secure), and > there are logistic difficulties as well; OpenSSL cannot be integrated > into a GPL'd program without the consent of every developer who has > ever committed a patch, which is impossible for gaim, and there > doesn't seem to be a clear and available alternative with a more > compatible license. the biggest thing is the logistical reasons. because of them, gaim will not have openssl support untill and unless openssl changes its license. We looked at a patch by rwscott to add gnutls support, but it was indefinitally postponed when we discovered that 1)gnutls does not build outside of a gnu environment, ie it does not build on solaris, macosx, win32, irix, or *bsd 2)the gnutls people are not interested in changing this situation. given that gaim is used on all of the above platforms and some not mentioned as well as linux, this intransigence on the part of the gnutls people causes us to reject the use of their library. luke -- -This email is made of 100% recycled electrons. |
|
From: Evan D. <ev...@ca...> - 2002-11-15 17:29:22
|
On Fri, 2002-11-15 at 10:56, Ethan Blanton wrote: > (Bringing this back to gaim-devel, I hope you don't mind.) > > Scott spake unto us the following wisdom: > > The presence bar is a pull down menu allowing you to select > > different away 'types' (in gabber: "Available", "Free to Chat", > > "Away", "Extended Away", "Busy", and "Invisible"). In Gaim, the > > functionality of the button bar is all replicated elsewhere, and is > > wasted space, imo. Currently when you are 'away', you get a text > > dialog with your away message and a button saying 'I'm Back' which > > again imo, is annoying and can get lost amongst a myriad of > > windows. It would be more tidy to have the pulldown menu to select > > and see your 'presence' at a glance in the gaim window. If you are using Gnome (or KDE, as I understand it) you should consider loading the "Tray Icon" plugin. You'll need to be running CVS Gaim. Right clicking on the tray icon (a.k.a. docklet) provides a list of common tasks, and if you are away, "Back" is one of them. > OpenSSL cannot be integrated > into a GPL'd program without the consent of every developer who has > ever committed a patch, which is impossible for gaim, and there > doesn't seem to be a clear and available alternative with a more > compatible license. I think this issue could be avoided if the Jabber-SSL was released as a plugin. Didn't Mozilla do that for a while? Doesn't gaim-e work with Jabber anyway? I understand that not everyone runs Gaim, but with the Windows client on the way and the problems with OpenSSL, that may be the simple solution. :) -- Evan Doughty ev...@ca... |
|
From: Ethan B. <ebl...@cs...> - 2002-11-15 15:58:43
|
(Bringing this back to gaim-devel, I hope you don't mind.)
Scott spake unto us the following wisdom:
> The presence bar is a pull down menu allowing you to select
> different away 'types' (in gabber: "Available", "Free to Chat",
> "Away", "Extended Away", "Busy", and "Invisible"). In Gaim, the
> functionality of the button bar is all replicated elsewhere, and is
> wasted space, imo. Currently when you are 'away', you get a text
> dialog with your away message and a button saying 'I'm Back' which
> again imo, is annoying and can get lost amongst a myriad of
> windows. It would be more tidy to have the pulldown menu to select
> and see your 'presence' at a glance in the gaim window.
Ahh. I agree that away-ness is rather complicated in gaim as things
stand right now; unfortunately, such a presence bar simply would not
work in gaim. It is perfectly reasonable (and common, even!) to have
different away states for different accounts (notice that you can
select an individual account from the menu when you choose to go
away). I personally also agree that buttons at the bottom of the
buddy list are mostly useless ... I use the preference item to turn
them off.
> Has there been any talk about getting SSL support for Jabber?
Yes, and it is not likely to happen soon or at all. There is an entry
in the FAQ about the security-related reasons (it isn't secure), and
there are logistic difficulties as well; OpenSSL cannot be integrated
into a GPL'd program without the consent of every developer who has
ever committed a patch, which is impossible for gaim, and there
doesn't seem to be a clear and available alternative with a more
compatible license.
Ethan
--=20
And if I claim to be a wise man / it surely means that I don't know.
-- Kansas, "Carry on Wayward Son"
|
|
From: Nathan W. <fac...@fa...> - 2002-11-15 05:52:23
|
On Thu, Nov 14, 2002 at 12:48:49PM -0800, Scott wrote: <snip> > Also, I would like to see proxies be moved into each account (maybe a button > for 'use default proxy'). This would be useful for people like me who have a > local jabber server in-house, and would also like to be able to connect to an > internet server. Although currently gaim jabber support does not allow for > different servers which is another thing that needs fixing! <snip> I've got a patch to do this, which is finished and waiting to be merged. If you want, you can grab the latest patch (against cvs) from http://faceprint.com/code/gaim/per-account-proxy.20021113.1818.diff Nathan -- Nathan Walp || fac...@fa... GPG Fingerprint: || http://faceprint.com/ 5509 6EF3 928B 2363 9B2B DA17 3E46 2CDC 492D DB7E |
|
From: Evan D. <ev...@ca...> - 2002-11-14 21:08:40
|
On Thu, 2002-11-14 at 16:00, Evan Doughty wrote: > Maybe you should just use Jabber. :) Oops. That should be Gabber, not Jabber. Duh. I make that mistake more often than I care to admit. :) -- Evan Doughty ev...@ca... |
|
From: Ethan B. <ebl...@cs...> - 2002-11-14 21:06:15
|
Scott spake unto us the following wisdom:
> Is there an effort to port GAIM to GTK2 and Glade dialogs?=20
Yes, gaim CVS is Gtk2 only. It will not use glade, though, and I'm
not sure why you might think this is necessary.
> I find the buddy editor to be not quite up to snuff. Have you seen the w=
ay
> Gabber deals with buddy list editing? It seems a lot more fluid. I can =
just
> right click on a buddy, and click remove, or just drag the name from grou=
p to
> group.
The buddy list will be rewritten at some point, as it uses widgets
which are deprecated in Gtk2. The rewrite will imporove its look &
feel.
> Also, I would like to see proxies be moved into each account (maybe a but=
ton
> for 'use default proxy'). This would be useful for people like me who ha=
ve a
> local jabber server in-house, and would also like to be able to connect t=
o an
> internet server. Although currently gaim jabber support does not allow f=
or
> different servers which is another thing that needs fixing!
Per-account proxies are in the works. I'm not sure what the status
is, but I know there is a working (at least mostly working) patch
hanging around.
Gaim jabber support allows for as many servers as you like. I'm not
sure what you're talking about there.
> I think the bottom icon bar should be replaced with something similar to
> gabbers 'presence' bar. The background color of the Group Name should be
> shaded like Gabber's as well, it makes the separation much clearer.
You seem to like a lot of things about Gabber ... gaim is not Gabber.
I'm not sure what gabber's "presence" bar is, but perhaps a clear
description of the functionality you would like would help more.
As far as group name looks, this may or may not change with the buddy
list rewrite.
> The preferences window in Gabber is also a lot clearer. Although its opt=
ions
> are not as numerious as gaim's, maybe a style more like Galeon's would be=
more
> in order.
Look at the gaim CVS preferences, it is in general much superior to
the stable version.
> These are my thoughts for bringing Gaim up to par. What do you think?
Where by "bringing Gaim up to par" you apparently mean "making Gaim
into Gabber". There may be features in other IM programs that are
desirable in gaim, and we try to incorporate them as much as possible.
However, if they do not fit the "total picture" of gaim (gaim has a
much more ambitious goal than being *just* a Jabber (or MSN, or
whatever) client), they may not be workable.
Presenting your feature list in such a fashion ("Why isn't gaim more
like gabber?" "Gaim is subpar because it doesn't have these specific
features that *I* like that you may or may not like.") is not likely
to win friends and influence developers. If your points have merit,
hopefully they won't be lost in the poor presentation.
Ethan
--=20
And if I claim to be a wise man / it surely means that I don't know.
-- Kansas, "Carry on Wayward Son"
|
|
From: Etan R. <de...@ed...> - 2002-11-14 20:59:17
|
> Is there an effort to port GAIM to GTK2 and Glade dialogs? Yes to gtk2, no to glade. gaim cvs is gtk2 only, and has been for a little while now. The 0.59.X branch is for gtk1.2 > Also, I would like to see proxies be moved into each account (maybe a button > for 'use default proxy'). This would be useful for people like me who have a > local jabber server in-house, and would also like to be able to connect to an > internet server. That's being worked on, IIRC it was working correctly, and was simply awaiting a proper GUI. > Although currently gaim jabber support does not allow for > different servers which is another thing that needs fixing! Yes it does, when you input your username just put it in fully specified (i.e. us...@se.../resource) > I think the bottom icon bar should be replaced with something similar to > gabbers 'presence' bar. Not sure what you mean. -Etan |
|
From: Evan D. <ev...@ca...> - 2002-11-14 20:57:41
|
Maybe you should just use Jabber. :) What version of Gaim are you using? CVS Gaim is significantly different than the official .59.x release. On Thu, 2002-11-14 at 15:48, Scott wrote: > Is there an effort to port GAIM to GTK2 and Glade dialogs? > > I find the buddy editor to be not quite up to snuff. Have you seen the way > Gabber deals with buddy list editing? It seems a lot more fluid. I can just > right click on a buddy, and click remove, or just drag the name from group to > group. > > Also, I would like to see proxies be moved into each account (maybe a button > for 'use default proxy'). This would be useful for people like me who have a > local jabber server in-house, and would also like to be able to connect to an > internet server. Although currently gaim jabber support does not allow for > different servers which is another thing that needs fixing! > > I think the bottom icon bar should be replaced with something similar to > gabbers 'presence' bar. The background color of the Group Name should be > shaded like Gabber's as well, it makes the separation much clearer. > > The preferences window in Gabber is also a lot clearer. Although its options > are not as numerious as gaim's, maybe a style more like Galeon's would be more > in order. > > These are my thoughts for bringing Gaim up to par. What do you think? > > -- Scott > > ===== > > > __________________________________________________ > Do you Yahoo!? > Yahoo! Web Hosting - Let the expert host your site > http://webhosting.yahoo.com > > > ------------------------------------------------------- > This sf.net email is sponsored by: To learn the basics of securing > your web site with SSL, click here to get a FREE TRIAL of a Thawte > Server Certificate: http://www.gothawte.com/rd524.html > _______________________________________________ > Gaim-devel mailing list > Gai...@li... > https://lists.sourceforge.net/lists/listinfo/gaim-devel -- Evan Doughty ev...@ca... |
|
From: Scott <net...@ya...> - 2002-11-14 20:48:50
|
Is there an effort to port GAIM to GTK2 and Glade dialogs? I find the buddy editor to be not quite up to snuff. Have you seen the way Gabber deals with buddy list editing? It seems a lot more fluid. I can just right click on a buddy, and click remove, or just drag the name from group to group. Also, I would like to see proxies be moved into each account (maybe a button for 'use default proxy'). This would be useful for people like me who have a local jabber server in-house, and would also like to be able to connect to an internet server. Although currently gaim jabber support does not allow for different servers which is another thing that needs fixing! I think the bottom icon bar should be replaced with something similar to gabbers 'presence' bar. The background color of the Group Name should be shaded like Gabber's as well, it makes the separation much clearer. The preferences window in Gabber is also a lot clearer. Although its options are not as numerious as gaim's, maybe a style more like Galeon's would be more in order. These are my thoughts for bringing Gaim up to par. What do you think? -- Scott ===== __________________________________________________ Do you Yahoo!? Yahoo! Web Hosting - Let the expert host your site http://webhosting.yahoo.com |
|
From: Christian H. <ch...@gn...> - 2002-11-14 19:41:03
|
On Sun, Nov 10, 2002 at 02:23:47PM -0500, Sean Egan wrote: > I share Chip's concern. When I first sat down to write the file > transfer GUI was the first time I looked at the API and I noticed this > right away. Wouldn't it be better for the prpl to handle its sockets > itself and have its own callback which can strip headers and stuff and > then call a generic function with a pointer and a length? That would > seem to be the optimal solution. > > Apart from writing gtkcellrendererprogress, I've not started the file > transfer GUI--Rob may have started--either way changes to ft.c would not > interfere with it much, I'm sure. > > -s. Funny how I just got this post. I *thought* I was missing something in the reply! The simple addition of read and write functions, defaulting to libc read() and write() if they're NULL, allowed for file transfer in MSN. It works beautifully, and I've received many documents and images so far. Now I just want that file transfer dialog! ;) Christian -- Christian Hammond <> The GNUpdate Project ch...@gn... <> http://www.gnupdate.org/ 96.7% of all statistics are made up. |
|
From: Sergey V. U. <ser...@cl...> - 2002-11-14 12:12:37
|
Hi all Just built gtkspell 2.0.3 and gaim 0.60 (from cvs), and noticed one problem. gaim uses the function gtkspell_attach which, in turn, makes gtkspell use the default language (from LANG envvar). That's not really nice. For many people (like me) this model is not quite correct because: 1. It is not possible to check against more than 1 language. The "ideal" solution is demostrated in evolution 1.2 - you can choose a _set_ of languages to check against. 2. I realize that (1) would require some major changes in gtkspell, but even without this there is appropriate solution: ability to assign the language to every buddy (and/or to the particular chat session). Hope my ideas will help to improve gaim. -- Sergey |
|
From: Sean E. <se...@se...> - 2002-11-14 11:26:12
|
I share Chip's concern. When I first sat down to write the file transfer GUI was the first time I looked at the API and I noticed this right away. Wouldn't it be better for the prpl to handle its sockets itself and have its own callback which can strip headers and stuff and then call a generic function with a pointer and a length? That would seem to be the optimal solution. Apart from writing gtkcellrendererprogress, I've not started the file transfer GUI--Rob may have started--either way changes to ft.c would not interfere with it much, I'm sure. -s. On Sun, 2002-11-10 at 14:08, Ethan Blanton wrote: > William T. Mahan spake unto us the following wisdom: > > On Sun, Nov 10, 2002 at 03:14:37AM -0800, Christian Hammond wrote: > > > > > > Basically, I need to be able to read in x amount of bytes, then say, > > > "Okay, you get 'y' many bytes and stick it in the file, and then call > > > me back when you're done and we'll continue this after I rest a bit." > > > > You're right, there's no easy way to do that using the current API. I > > was hoping that no sane protocol would break up a file and send > > headers in the middle, since it's not necessary over TCP. Apparently > > that was a bad assumption. :-( > > ... But what if you want to interleave FT and other info on the same > stream? I can see this as being a very reasonable thing to do. > > Ethan > > -- > And if I claim to be a wise man / it surely means that I don't know. > -- Kansas, "Carry on Wayward Son" |
|
From: <ma...@cs...> - 2002-11-14 03:19:38
|
I have released GtkSpell 2.0.3. Relevant changes since GtkSpell 2.0.2: - Hack around Pango word-breaking bug: http://bugzilla.gnome.org/show_bug.cgi?id=97545 so we no longer incorrectly flag words with apostrophes as misspellings. - RPM spec file generated by configure. - Better configure-time detection of libpspell (helps users diagnose why it won't compile). It is available at http://gtkspell.sf.net. [If you'd prefer me not to spam your mailing list, please let me know; I've included you because your projects use GtkSpell.] -- Evan Martin ma...@cs... http://neugierig.org |
|
From: Reinout v. S. <re...@cs...> - 2002-11-11 21:06:38
|
Hi, Here's a slightly updated Dutch Gaim translation. It's not finished yet but it's as far as I got tonight... -- Reinout van Schouwen Artificial Intelligence student email: re...@cs... mobile phone: +31-6-44360778 GPG public key http://www.cs.vu.nl/~reinout/reinout.asc |
|
From: Christian H. <ch...@gn...> - 2002-11-11 10:55:45
|
On Mon, Nov 11, 2002 at 01:41:11AM -0800, Marcel Birthelmer wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > | You'll probably get them soon :) My friend, Steph, has pics for me. I > | want them. > ... > | Christian > | > > Chip gonna get some cyber-booty. Actually, no.. we're just friends... Christian -- Christian Hammond <> The GNUpdate Project ch...@gn... <> http://www.gnupdate.org/ What is it, Lassie? A boy fell down a mine shaft and broke his ankle and is diabetic and needs insulin? Is THAT what you're trying to tell me? |
|
From: Marcel B. <ma...@ca...> - 2002-11-11 09:42:29
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 | You'll probably get them soon :) My friend, Steph, has pics for me. I | want them. ... | Christian | Chip gonna get some cyber-booty. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE9z3s3RP2ZrlyJqb0RAggfAKC0XdCxITNRRooIfCf7q8yXdjahnACgoKrW S+vfvyaULJSN9WEKcDnmvUw= =YwKY -----END PGP SIGNATURE----- |
|
From: Christian H. <ch...@gn...> - 2002-11-11 02:40:27
|
On Sun, Nov 10, 2002 at 09:16:58PM -0500, William T. Mahan wrote: > On Sun, Nov 10, 2002 at 03:39:16PM -0500, Ethan Blanton wrote: > > > > I'm not sure precisely what read/write while loops you're speaking of, > > but we *really* need to avoid I/O requiring synchronicity (yes, that's > > What I meant is that the I/O handlers that actually call read() and > write() on sockets will need to be moved out of the generic ft.c and > into the prpls. This means more work for the prpls but a simpler > interface. There's a simple solution for this. You just add two new functions to the prpl interface. One for reading, one for writing. Before doing a read() or write() (you should be using these instead of the loops ANYWAY, or at least a less costly function, like fgetc or fputc) you should check if these functions are NULL. If they're NULL, use read/write. If not, use the functions. > OK, here's my shot at a new interface. What follows is the part > visible to the prpls (i.e. this goes in prpl.h). I haven't had a chance to read it yet. I'll look at it in a sec. > This is somewhat different from the current API, but I want to get it > right this time; comments are welcome. You'll probably get them soon :) My friend, Steph, has pics for me. I want them. This is why MSN is about to have file transfer, but that won't be done until the FT API works with it... so I have some incentive at the moment ;) Christian -- Christian Hammond <> The GNUpdate Project ch...@gn... <> http://www.gnupdate.org/ Why doesn't the Bat Computer ever crash? |
|
From: William T. M. <wt...@du...> - 2002-11-11 02:18:29
|
On Sun, Nov 10, 2002 at 03:39:16PM -0500, Ethan Blanton wrote:
>
> I'm not sure precisely what read/write while loops you're speaking of,
> but we *really* need to avoid I/O requiring synchronicity (yes, that's
What I meant is that the I/O handlers that actually call read() and
write() on sockets will need to be moved out of the generic ft.c and
into the prpls. This means more work for the prpls but a simpler
interface.
> a word) wherever possible. If a read or write fails to complete 100%
> (i.e. you wanted a 2k packet and you only got 1k of it), you need to
> mark this down someplace and hand control back to gaim until your
> socket comes up as readable again. forcing synchronicity is where we
> get the lags we have in the UI ... most (if not all) of our sockets
> are actually nonblocking, we just force blocking behavior in places.
I agree with your point in general, although I think if you look at
the FT code in particular you will find that it is nicely
asynchronous. :)
> This may mean that prpls need to keep track of more state on a
> per-connection or per-socket basis, but it's worth the effort...
OK, here's my shot at a new interface. What follows is the part
visible to the prpls (i.e. this goes in prpl.h).
This is somewhat different from the current API, but I want to get it
right this time; comments are welcome.
======
/* A struct, opaque to the prpls, that uniquely identifies
* a file transfer session (a session consists of sending
* one or more files to a given user).
*/
struct file_transfer;
/* Functions called by the prpls */
/* ----------------------------- */
/* Set up an incoming session; this will prompt the user whether to
* accept the transfer, where to put the files, etc.
*/
extern struct file_transfer *file_transfer_in_add(struct gaim_connection *gc,
const char *who, const char *name, long totsize,
long totfiles, const char *msg);
/* Set up an outgoing session; this will prompt the user for which
* file(s) to send.
*/
extern struct file_transfer *file_transfer_out_add(struct gaim_connection *gc,
const char *who);
/* For outgoing transfers, this is called before sending each file
* to get the filename and size; and to set the offset for resuming.
* For incoming transfers, this is called before receiving each file
* to set the filename and size; and to get the offset for resuming.
* Also opens the file for reading/writing as appropriate.
*/
extern int file_transfer_start_file(struct file_transfer *xfer,
char **filename, long *size, long *offset);
/* Read or write a chunk of data. For incoming transfers,
* reads from buf and writes to a file; for outgoing transfers,
* reads from a file and writes to buf.
*/
extern int file_transfer_do_chunk(struct file_transfer *xfer,
char *buf, int len);
/* This is used to get information about a session.
*/
extern int file_transfer_get_info(struct file_transfer *xfer,
char **name, long *totfiles, long *totsize);
/* Abort a session in progress. */
extern int file_transfer_abort(struct file_transfer *xfer, const char *why);
/* Callbacks that each prpl should provide */
/* --------------------------------------- */
struct prpl {
/* ... */
/* A session was successfully set up; the prpl may begin sending
* or receiving the first file.
*/
void (* file_transfer_added) (struct gaim_connection *gc, struct file_transfer *xfer);
/* A session was canceled by the user; the prpl should clean up. */
void (* file_transfer_canceled) (struct gaim_connection *gc, struct file_transfer *xfer);
};
-- Wil
|
171 messages has been excluded from this view by a project administrator.
