[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: Difficulties implementing a search KIO slave
From:       Michael Howell <mhowell123 () gmail ! com>
Date:       2008-12-09 22:34:14
Message-ID: 200812091534.18344.mhowell123 () gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Tuesday 09 December 2008 1:37:51 am Jean-Francois Dockes wrote:
> Michael Howell writes:
>  > On Saturday 06 December 2008 9:39:43 am Jean-Francois Dockes wrote:
>  > > KIO slaves being stateless makes their design awkward. Out of
>  > > curiosity, I had a look at other modules. It is, for example, a bit
>  > > weird to see kio-ftp having to reconnect for each operation if there
>  > > are two windows open on different servers... Could get ugly if the
>  > > servers are busy.
>  >
>  > There may be a reason not to, but how about using a map from the server
>  > to an internal state. In pseudo-C++:
>  >
>  > class Instance {
>  >     Instance(String server)
>  >    {
>  >         s_instances[server] = this;
>  >         connectToServer();
>  >     }
>  >     // stuff
>  >     static Map<String, Instance*> s_instances;
>  > };
>  > class Slave : public AbstractSlave {
>  >     void get(Url url)
>  >     {
>  >         new Instance(url.getServer());
>  >         // stuff
>  >     }
>  >     // stuff
>  > };
>  >
>  > Yes, I will look into using this in KIO_FTP. Yes, I also noticed the
>  > memory leak and will look into that, too.
>
> I am not completely sure I understand what you intend to do, but you do
> realize that the situation with one konqueror window and several slaves is
> also possible ?
>
> There is simply no keeping state in slaves, the only place to store things
> between invocations is the URL, and this is also quite constrained because
> of its interpretation by the upper layers.
>
> So, if a KIO slave needs session persistence, the only way as far as I
> understand is to place some kind of session id in the URL and have a
> separate process (or data store) to keep session data. As we say in French,
> "une usine �� gaz" (many tubes, as complicated as an oil refinery). Same
> issues as for www server side programming actually (but no cookies
> allowed).
>
> What would be nice would be a way to tell the job scheduler that a given
> protocol should be handled by process-private, single-instance slaves,
> behaving more like a dlopen'd extension. This could be controlled by an
> attribute in the protocol file.
>
> Maybe the existing FORK_SLAVES thing could be a basis for the
> process-private part, but I don't understand enough about the job scheduler
> to know if all this makes any sense, and is a feasible and/or acceptable
> modification. As a KDE newbie, I am really out of my league here.
>
> Cheers,
> J.F. Dockes
>
> >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to
> >> unsubscribe <<
Actually, I was being stupid and had forgotten that each slave runs in a 
separate process. If it were inner-process, it'd be easy (store it in a static 
map between servers and connections).

-- 
Michael Howell
mhowell123@gmail.com


["signature.asc" (application/pgp-signature)]

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<


[prev in list] [next in list] [prev in thread] [next in thread]