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

List:       kfm-devel
Subject:    protocol stuff (was: Re: KFM Error)
From:       Simon Hausmann <tronical () gmx ! net>
Date:       1999-03-31 14:02:22
[Download RAW message or body]


On Tue, 30 Mar 1999, Alex Zepeda wrote:

> > Since we are already able to do such associations I like your idea of
> > mapping a certain protocol to a mime type.
> > The corresponding changes in KRun should be trivial, the
> > question/problem is IMHO more like: Where do we configure this
> > mapping? kio.kfg and mimelnk?
> 
> Probably in mimelink, perhaps x-protocol/telnet?  Since if all else fails,
> there could be some sort of fallback slave that'd setup the x-protocol/foo
> mime binding..

Yes, so I think we have two choices:

1) We can either create an additional Mimetype inside likbio
(just like it is currently done with .kdelnk's, for example:
KProtocolMimeType) and integrate this into krun and kservice.

2) Or (if I understand you correctly) we can create a special kioslave,
being called whenever the protocol lookup for a slave fails (someting like
"DefaultProtocolSlave" ) . This slave might then look for the appropriate
bindings.

Since I'm not really sure about 2) (...and I'm not sure whether I really
understand the idea ;) ) I think 1) is the better way to go. This would
also make sure that the additional protocol services, not being handled by
the protocol manager, are not available for kiojob, but only explicitly or
by krun.
Hm,... I start really getting confused about this ;-) .
Do we really want to "override" the protocol manager for protocols not
being handled by an ioslave?


Greetings,
 Simon

> > Or are there any other ideas/suggestions of how to handle such "slaveless"
> > protocols?
> 
> - alex
> 

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