[PATCH] Request for adding internal meta-data support to KIO...

Rolf Eike Beer kde at opensource.sf-tec.de
Fri Apr 30 19:14:05 BST 2010

Dawit A wrote:
> On Thursday, April 29, 2010 02:14:45 Rolf Eike Beer wrote:

> > My point is less a thing that this (or any other) slave will do or not
> > with this data now or in one year. My point is that when this is some
> > internal state of whatever kind than we should under no way allow remote
> > systems to influence that in any way but through our code that does it
> > explicitely. It's the same like you make class members private instead
> > of making them public and hoping that noone will touch them if you name
> > them
> > _private_member_foo.
> Again there is no way for a remote system to influence the meta-data
> system, internal or otherwise, right now unless the developer of an
> ioslave implicitly allows it to do so. As such I fail to see how you can
> protect against that by using special characters in the keyword. If the
> developer is going to expose it to influence by the remote system, what
> stops him from simply adding the keyword directly ? To me it is simply a
> pointless exercise since you cannot control what a developer will do in
> the end. What you are saying would make a great deal of sense if we
> automatically mapped meta-data sent by a remote system directly into our
> internal scheme, but we do not do that.

Ok, so if there is no way to put "global" entries in the metadata everything 
is fine. The HTTP ioslave e.g. puts everything in the Content-Disposition 
header as Content-Disposition-foo in the metadata. If noone inserts un-prefixed 
wildcard data in the metadata we're save.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20100430/7794b997/attachment.sig>

More information about the kde-core-devel mailing list