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

List:       kde-core-devel
Subject:    Re: Addition to kio-SlaveBase (V. II)
From:       Bjoern Kahl <Bjoern.Kahl () kiel ! netsurf ! de>
Date:       2000-07-16 0:29:54
[Download RAW message or body]


On 15-Jul-00 Stephan Kulow wrote:
>  Bjoern Kahl wrote:
> > 
> > > >
> > > >  No, for the concept, it has to be done in the slave (-base).
> > > >
> > > >  It can't be done in scheduler. The scheduler tells a
> > > >  slave to get some peace of data. The scheduler doesn't
> > > >  known if it is a network-resource, or a local file.
> > >  The slave doesn't know this either, the netmgr knows that!
> > >
> > >  Actually all the slavebase does is to take tasks from the
> > >  scheduler and call some functions in the slave. So the
> > >  slavebase doesn't know anything more than the scheduler
> > >  (or the KIO::Slave) knew before.
> > 
> >   Hmm. It is true that the slavebase is at first a
> >   communication layer to the scheduler. But it is the
> >   slaves side, so the slave can easily report things
> >   back. This way, slavebase knows what the slave knows.
> > 
>  OK, I added now requestNetwork and dropNetwork to slavebase.
>  Both take a host as argument (I see no reason why the netmgr
>  wants to know the rest as the concept of an host is in some
>  slaves not what the netmgr thinks of a host - so I thought
>  it's safer this way)
>  Calls to these functions result in a call to 
>  slaveinterface::request/dropNetwork. There you should be able
>  to implement your netmgr calls. There you can use things
>  like kapp->dcopClient kapp->instanceName and all this, so
>  you don't need any other heuristics


 Thanks, looks good. 

 But there is a new problem:
 requestNetwork is per definitionem a blocking call (have
 to wait until dialing is done). In the slave, this was no
 problem.
 In the application (slaveinterface/scheduler) this would
 freeze the app! If I make this call asynchronous (DCOP->send,
 not DCOP->call) then I need a registered app so I can get
 back the result with a DCOP->send from KNetMgr. This will
 requiere a DCOP-interface in slaveinterface and more
 statetracking about which slave is waiting for a result
 from KNetMgr.
 It could be done, but it is a lot of work.

 Is a saved DCOP-client in slavebase worth this amount of
 complexity?
 I still think having requestNetwork() and dropNetwork()
 in slavebase (defined like in your patch) and the needed
 rest of my addition (incl. dcop) in SlaveBasePrivate is
 a cleaner solution.


 Greetings, Bjoern

P.S.:
  Because I am moving, I am away from my mail on Monday and Tuesday.
-- 
+-----------------------------------------------------------------------+
| Björn Kahl ++ Max-Planck-Str.26 ++ 24211 Preetz ++ (ISDN) 04342 76882 |
+-----------------------------------------------------------------------+
 Weitergabe und/oder gewerbliche Nutzung meiner Adresse/TeleNr untersagt.

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