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

[Dawit A]

Attached is the same patch with the following changes:

#1. Use descriptive names for the scope portion of the keyword. 0 was replaced 
with "currenthost" and 1 with "allhosts".

#2. Removed the "kio~" portion of the keyword as that is already implied. 
After all this is still the KIO metadata system ; so now the full keyword used 
to mark a metadata as internal is either {internal~currenthost} or 
{internal~allhosts}

#3. When internal metadata is received, update ALL ioslaves, not only the 
idles ones, that match the criteria specified through the keyword.


On Monday, May 03, 2010 09:31:58 David Faure wrote:
> On Friday 30 April 2010, 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.
> 
> Yes. Don't confuse metadata with HTTP headers, even if in some cases
> there's some overlap.
> The HTTP headers sent by the webservers are NOT put into the metadata as
> one entry per header.
> 
> 
> About the naming: I think 0 and 1 should be replaced with descriptive
> names.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kio_internal_metadata.patch
Type: text/x-patch
Size: 5907 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20100503/dc7d9d37/attachment.bin>