On 2008-01-12 23:59:18 +0300, Tomash Brechko wrote: > On Sat, Jan 12, 2008 at 12:25:57 -0800, Dustin Sallings wrote: > > I don't understand why you wouldn't want UTF-8 in common. > > Because I think that such flag would be a mistake, and want to limit > the damage it will cause. Imagine the application that reads a > key/value pair, and stores it to memcached (Brian may have one). If > we decide to relay on UTF-8 flag when fetching data, then such app now > would have to ask, "Dear user, but what's the meaning of the data we > are uploading? Is it binary, or a non-ASCII text?"
Well what is "the application" going to do with this data? It should
know what the data is and means, so it can decide whether its a binary
or text. ("The application" for me is the whole thing - a script to
pre-warm a cache isn't an application, it is part of an application)
So I don't see that as a problem.
If you need a "put arbitrary values into a memcached" utility for some
reason, it also needs to be able to set arbitrary flags, so that's not a
problem either.
> (the data may come from arbitrary file, you can't assume it will
> always be the text encoded according to user's locale).
An application reading a file still needs to know how to interpret the
file. Again, If you do something like
sub get_info {
my ($file_handle, $memcache, $key) = @_;
my $info = $memcache->get($key);
return $info if defined $info;
search_key_in_file($file_handle, $key);
$info = <$file_handle>;
return $info;
}
it should work. Currently it doesn't.
> This information is obviously
> not relevant for the uploading process itself, but we would be bound
> to decide how the data would be retrieved later.
memcached is a cache. You put data there which you got from some other
source. And you expect to get the data back that you stored in the
cache. If the application wants to cache the raw, uninterpreted contents
of files in the cache, it can certainly do this. But raw file contents
aren't the only thing which should be cached (actually I would expect
that to be rather rare). Normally the thing you want to cache is the
result of a more complex operation.
> I find this very ridiculous.
I find it ridiculous that Cache::Memcached can handle arbitrarily nested
data structures but not simple strings.
> > What do people use flags for currently other than to indicate data
> > type?
>
> At least in Perl, when you serialize data its type is encoded in the
> new value, not separately in flags.
But the fact that the value stored was created by calling
Storable::nfreeze on a reference *is* stored in the flags. Otherwise get
wouldn't know that it needs to thaw the data before returning it to the
application.
And the fact that the value stored has been compressed using gzip *is*
stored in the flags. Otherwise get wouldn't know that it needs to unzip
the data before returning it to the application.
Similarily, the fact that the value stored was created utf8-encoding a
character stream must be recorded in a flag. Otherwise get cannot know
that that is must utf8-decode the data before returning it to the
application.
These cases are exactly equivalent: If you do some conversion before you
store the value, you must store the fact that you performed that
conversion somewhere so that you can revert it.
hp
--
_ | Peter J. Holzer | It took a genius to create [TeX],
|_|_) | Sysadmin WSR | and it takes a genius to maintain it.
| | | [EMAIL PROTECTED] | That's not engineering, that's art.
__/ | http://www.hjp.at/ | -- David Kastrup in comp.text.tex
signature.asc
Description: Digital signature
