Lee Daniel Crocker wrote: > > > Suppose you have a field named storable.publicationyear . Now the node can > > *by definition* not know what type this field is, as all the storable > > fields contain metadata which is processed by the clients. > > The field's type is "Storable.PublicationYear". What you want to do is > say that it and other such fields are encoded in a standard small set of > ways, such as decimal integers, dates, etc.
Well as I see it "Storable.PublicationYear" is more than it's type, as it is the identifier of the field. I agree with you that this includes the information about it's type (that's what you call strong typing i think), but the mapping field identifier->type cannot alway be done by the node. PLUS, and I think that's Oscar's problem, it cannot be done by all parts of the code. That's why Oscar wants the basic parsing code be able to work on the field without having a specific knowledge about what the field identifier means. (correct me if 'Im wrong) > ... > > Actually, that's a good argument--thanks again for finally finding > one I understand. We don't _need_ them really, but being able to > compare values for searches is indeed a useful function of weak typing, > because it allows comparisons to specified more simply. Without weak > typing, it could still be done by allowing the comparator to specify the > type: "dateCompare(Storable.PublicationDate,today) < 1" or something. I agree, you could be done this way, but this would put the load on the end user'S shoulders (if I understand you correctly), which I would rather avoid. > In this particular case, I'd rather have a common "Date" type that > serveral fields could share, encoded in an ISO standard format that is > easily comparable (e.g. "2000-05-15 13:01:54", UTC only). I'd probably compare values in epoc time (this allows for Ian's fuzzy results) but I agree we should have some standard format for dates. If we go with seconds since epoc (as an integer value) that's fine with me, if we decide on a human readable format like the one above, that's ok too. > How about this compromise: We define a small set of "encodings" for > fields, that can be used for operations like comparison and whatever > Oskar and Scott have in mind (which I still don't quite understand). > But the spec makes it clear that name==type, and all applications > are forbidden to modify, delete, or add fields based on nothing but > these encodings, and that these encodings must all be representable > and fully transportable as strings, so that applications treating > them as such will not lose information. Every field's purpose is > defined totally and exclusively by its name, and only one encoding > is allowed for any defined type. This sounds very good. If applications just copy the whole string (possibly including the quotes around a "real" string) this should work in all cases (excapt HTL of course, which has to be parsed either way). Just two additions to the following sentence: "Every field's purpose is defined totally and exclusively by its name, and only one encoding is allowed for any defined type." - It should be stated explicitly that different subfields to the same field ofcourse _can_ have different purposes and therefore different types. - As I understand it, "storable.*" is a client issue. So if every subfield must have a well defined purpose and therefore an explicitly defined type (which I think is a good and clean approach) it must be clear that the client authors have to do this for all subfields of storable, as this is not a responsibility of the core developers (and the official proto spec'ing guy, aka LDC :) ) Apart from this, I'm fine with your compromise. Now we just need to decide how the different types should look. I'm fine with Oscar's first suggestion (all integers hex, all strings in doublequotes) but someone might disagree. Add to that the two ideas for dates above and go discuss. :) CU, Philipp _______________________________________________ Freenet-dev mailing list Freenet-dev at lists.sourceforge.net http://lists.sourceforge.net/mailman/listinfo/freenet-dev
