Closed Bug 240160 Opened 21 years ago Closed 9 months ago

rdf should support 64-bit integers

Categories

(Core Graveyard :: RDF, enhancement)

enhancement
Not set
normal

Tracking

(Not tracked)

RESOLVED INCOMPLETE

People

(Reporter: Biesinger, Unassigned)

References

Details

RDF should support 64-bit integers. Currently, it only supports 32-bit ones with nsIRDFInt. I suggest adding nsIRDFInt64, which stores PRInt64 values. Serialisation is done like for nsIRDFInt, using AppendInt on an nsAutoString (as added in bug 240106) Deserialization can use PR_sscanf: http://www.mozilla.org/projects/nspr/reference/html/prprf.html#23627 Changing nsIRDFInt to use 64-bit integers instead of 32-bit ones would have the downside of increasing bloat, and breaking code that depends on it storing 32-bit numbers.
Do we have a use-case for this? I don't want to add all kinds of RDF literal interfaces without a need in the code. I'm hoping to move RDF literals over to real typed-literals (per the RDF spec) in the 1.8 timeframe. There is an XML schema datatype for 32-bit integer types (as well as 8, 16, and 64-bit types), but unless/until we actually have a use for them in mozilla code, we can just support them as string literals.
We don't have any arguments to restrict plain RDF integers on 32 bits. Which makes it kinda hard to make a good case for 64bits. Benjamin, from the bloat point of view, do we wanna have all literals implement rdfILiteral, which would require us to store the string, too. Though, literals are singletons, so the bloat might not be the worst issue. Anyway, if they did, we could just do a method to get the int value as 64bit. How does the current implementation handle overflows? At least the parsing fails pretty bad, so cutting down to 32 bits might be a compatibility question in general.
(In reply to comment #2) > Benjamin, from the bloat point of view, do we wanna have all literals implement > rdfILiteral, which would require us to store the string, too. Though, literals Yes, they should all implement nsIRDFLiteral... however, I plan to remove the GetValueConst method and use sharable strings. That way, we don't have to keep the string representation as a member, merely generate the string as necessary for these odd numeric types. What underlying XML Schema type do we want? They are all bounded integers, and IMO using the 32-bit type is fine for all mozilla code that I've seen. http://www.w3.org/TR/xmlschema-2/#int (we could also use #long, if someone comes up with a good 64-bit use case)
(In reply to comment #1) > Do we have a use-case for this? we do - xul directory viewer should support 64bit filesizes
(In reply to comment #3) > Yes, they should all implement nsIRDFLiteral... then nsIRDFInt etc should probably inherit from nsIRDFLiteral... which in itself should probably inherit from nsIRDFNode - all literals are nodes, right?
(In reply to comment #3) > (In reply to comment #2) > > Benjamin, from the bloat point of view, do we wanna have all literals implement > > rdfILiteral, which would require us to store the string, too. Though, literals > > Yes, they should all implement nsIRDFLiteral... however, I plan to remove the > GetValueConst method and use sharable strings. That way, we don't have to keep > the string representation as a member, merely generate the string as necessary > for these odd numeric types. Read a bit of specs over easter, and I'm not convinced that it is a good idea to make literals have a string representation in general. Perhaps a toString(). But not a stringValue member. That'd be confusing, I guess. Insert blurb about lexical and value space and the mapping being good from lexical to value, but not back.
> Read a bit of specs over easter, and I'm not convinced that it is a good idea > to make literals have a string representation in general. Perhaps a > toString(). But not a stringValue member. That'd be confusing, I guess. What is the difference? I mean, I don't much care what the methbod is called, but for serialization purposes we need to be able to convert RDF literals of any type into a string, and preferably the normalized version of the datatype.
(In reply to comment #1) > but unless/until we actually have a use for them in mozilla code, we can just > support them as string literals. integers that are treated as string literals don't sort very well...
Storing everything as strings is a bad idea (and one I don't think bsmedberg is actually proposing in comment #3 -- if GetValueConst goes away, we can just build the string on the fly), but requiring everything to be able to serialize itself might be useful. At that point we may want to consider moving |Value| into nsIRDFNode (leaving GetValueConst on nsIRDFResource only?), just to ensure any future node types can be serialized as well. As a side note, integers (and a couple of other small, fixed-size literals) should probably be coming from a pool, rather than straight off the heap.
Severity: normal → enhancement
this is no longer important to me, the place where I wanted this is using strings now. -> default owner
Assignee: cbiesinger → nobody
QA Contact: core.rdf
Product: Core → Core Graveyard
Status: NEW → RESOLVED
Closed: 9 months ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.