240160 - rdf should support 64-bit integers

Status: RESOLVED INCOMPLETE

(Core Graveyard :: RDF, enhancement)

Description

[Christian :Biesinger (don't email me, ping me on IRC)]

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.

Comment 1

[Benjamin Smedberg]

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.

Comment 2

[Axel Hecht]

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.

Comment 3

[Benjamin Smedberg]

(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)

Comment 4

[Christian :Biesinger (don't email me, ping me on IRC)]

(In reply to comment #1)
> Do we have a use-case for this?

we do - xul directory viewer should support 64bit filesizes

Comment 5

[Christian :Biesinger (don't email me, ping me on IRC)]

(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?

Comment 6

[Axel Hecht]

(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.

Comment 7

[Benjamin Smedberg]

> 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.

Comment 8

[Christian :Biesinger (don't email me, ping me on IRC)]

(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...

Comment 9

[Chase Tingley]

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.

Comment 10

[Christian :Biesinger (don't email me, ping me on IRC)]

this is no longer important to me, the place where I wanted this is using
strings now. -> default owner