From what i read of silc, i would like to see this eventually go in, but
some of Christian's points are at least temorarily valid. I would be
very interested in seeing any patch you could come up with that would
exand the current api to be sufficient for the needs of this protocol.
On Thu, Mar 04, 2004 at 08:16:20PM +0100, Pekka Riikonen wrote:
> : > The GTK specific thing that I'm doing in the file transfer is calling to
> : > show the file transfer dialog. All other operations are done via the
> : > normal FT API. If the dialog could be showed via the FT API it would be
> : > possible to remove the use of GTK API.
> : I think you misunderstand what a core/UI split is. Unfortunately, most
> : people do.
> : A core/UI split doesn't just abstract a traditional WIMP GUI.
> : *Nothing* in the core should know anything about a file transfer
> : dialor or a file selector dialog. They shouldn't know they exist, and
> : they shouldn't request one, ever. Also, passing keys around isn't
> : traditional file transfer, so you can't use the FT API.
> I didn't misunderstand it. I understand it really well. Me using those
> functions (or that one function) is me showing you (gaim-devel in general
> actually) that I couldn't use the current API to do a file transfer. I
> had to go around to make it happen, and it was deliberate, but only
> because I didn't have time at that point to open this discussion, but
> wanted to implement it first. The problem currently is that the FT API
> does not allow any kind of actual file transfer protocol management, what
> SFTP requires. For simple HTTP GET to a remote host is another matter,
> but unfortunately SFTP isn't stream based file transfer protocol at all.
> It is also not just about transferring "a file". It could allow complex
> file and directory transfers, and even file and directory manipulation.
> But, that's not what I'm after at all, however.
> What I am proposing is that the gaim_xfer_request allows prpl to define
> the text that is shows the user, and if needed not to ask user to save the
> file. We can't ask that, because we don't know what we are saving. And
> we can't use the default text, because it tries to show the filename
> (which would be (null)). In addition of this, we'd need a mechanism to
> later pop up the file saving to the user. Everything in SFTP is
> asynchronous, opening a file, closing a file, reading data, writing data,
> everything. We don't have everything in ready at the same moment, which
> the FT API currently requires for incoming file transfer _request_. And I
> emphasized that word because it's a "request for file transfer". This is
> exactly what it is in SFTP, not a request to _save_ a file, yet, at that
> point. That point comes a bit later. Some protocols can do it
> immediately after user says Ok, but we can't in SFTP. So I propose that
> it would be a separate procedure for the prpl to perform.
> If we could do this change to FT API, by still using the
> gaim_xfer_request, but with more versatility I see no reason for using any
> UI specific stuff from prpl for file transfers. The FT API is good for
> the simple stream based, HTTP GET style, file transfers, and with a little
> more work it could allow more versatile use. I belive this would benefit
> all file transfer protocols, current and future, not just SFTP.
> : > Yes. I needed to add the file selector for both file transfer, to ask
> : > user to save the file, and for importing public keys to buddies. IMO, the
> : > file selector could be an utility function in the Gaim core for prpls that
> : Receive the key, store it in a file or prefs or something. Make it
> : transparent to the user. If they really have to select a key for
> : something, use the gaim_request_fields API and present a list. A list
> : is a very basic element that can be represented by practically
> : anything.
> No it's not used like that at all. That thing you described is already
> there, with the list and everything. A grep from the SILC prpl shows (if
> we exclude the file transfer) the file selector use in the buddy list
> public key importing and in the channel public key management dialog to
> import a public key to the channel public key list.
> The file selector is used in cases where user has to select a public key,
> that does not exist anywhere in the software, to be imported, to for
> example in the channel public key list. It could be any public key,
> downloaded from any place, or received via email, or something. What ever
> way it was received it is usually saved to a file. User has to have the
> ability to import the public key from file to the software (usually to the
> list, you mentioned). Best example is this channel public key list;
> you're the founder of a channel and manage the channel public key list.
> You then import all the public keys to the list that you allow to access
> your channel. Or maybe you import just one key, that all users use to
> join that channel.
> If you can think any other mechanism of importing file content to
> software, than opening a file selector I would be happy to hear that
> alternative. It would also be nice hear why do you think that having a
> utility like that (gaim_filesel, gaim_file_selector, or something), or
> maybe a hint to the request API like Tim suggested, isn't Ok?
> Pekka Riikonen priikone at silcnet.org
> Secure Internet Live Conferencing (SILC) http://silcnet.org/
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> Gaim-devel mailing list
-This email is made of 100% recycled electrons.