On Friday, April 30, 2010 14:14:05 Rolf Eike Beer wrote:
> 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.

Right, but I have changed the keyword to "{kio~internal~[0-1]}" anyhow since 
the characters it is composed of does not matter. In fact with the change the 
keyword now looks sufficiently unique and will not be confused for with a 
regular metadata...

Regards,
Dawit A.