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

List:       kde-core-devel
Subject:    Re: [PATCH] Request for adding internal meta-data support to KIO...
From:       Rolf Eike Beer <kde () opensource ! sf-tec ! de>
Date:       2010-04-30 18:14:05
Message-ID: 201004302014.05728.kde () opensource ! sf-tec ! de
[Download RAW message or body]


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.

Eike

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

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