Proposal for dealing with fractional mtime

[ribasushi]

(ab)use the repeated type to have an identical wire-level representation
without using too many field numbers ( we are already half way through the
15 easy-ones available )

[achingbrain]

I think the spec should have an opinion about default values. It currently says:

This defaults to the unix epoch if unspecified

Any reason not to do this?

[ribasushi]

@achingbrain this is the same issue you had with mode: we need a way to represent "no mtime has been supplied". For FUSE-like bridges this would mean either epoch or now() at time of mount, and we could very well define this in spec. But for the web-gateway it should remain a N/A or - or something like that.

[achingbrain]

now() at time of mount would probably need storing somewhere which might be problematic, probably saver to opt for epoch.

But for the web-gateway it should remain a N/A or - or something like that.

Why is that?

[ribasushi]

Because... there is no mtime attached != Jan 1st 1970?

I guess I am not understanding the question, can you clarify?

[achingbrain]

So I guess we're saying something like:

If the existence of mtime is important for your application, use 0 where it is not set

Seems fair enough. Seeing 1970 everywhere when doing ls -l style mfs directory listings is bugging me a little. I'd rather see - in it's place.

[Stebalien]

I think the issue is that:

1. Operating systems expect some mtime and we want to be consistent.
2. If we pick the epoch, the mtime will always be consistent. If we pick the mount time, it'll change every time we restart.

[achingbrain]

On that basis we should probably stick with 0 as the default mtime as it is now.

[achingbrain]

I'm not a fan of having so much interpretation in a spec - the more an implementer has to understand in order to implement something, the more chances are of them getting it wrong.

Using an unbounded list for this also opens it up to abuse.

Why not just have two optional fields - mtime for seconds and mtime_nsec for nanoseconds since the last second? Both default to 0 and the combination of which gives you the time.

From what I can see the serialized size of such messages is the same:

`
message TwoFields {
  optional int32 mtime = 1;
  optional int32 mtime_nsec = 2;
}

message RepeatedField {
  repeated int32 mtime = 1;
}
`

console.info(TwoFields.encode({
  mtime: 1,
  mtime_nsec: 1
}).length) // 4

console.info(RepeatedField.encode({
  mtime: [1, 1]
}).length) // 4

[ribasushi]

I would vastly prefer something like:

message Data {
	enum DataType {
		Raw = 0;
		Directory = 1;
		File = 2;
		Metadata = 3;
		Symlink = 4;
		HAMTShard = 5;
	}

	required DataType Type = 1;
	optional bytes Data = 2;
	optional uint64 filesize = 3;
	repeated uint64 blocksizes = 4;
	optional uint64 hashType = 5;
	optional uint64 fanout = 6;
	optional uint32 mode = 7;
	optional TimeSpec mtime = 8;
}

message TimeSpec {
  required int64 EpochSeconds = 1;
  optional uint32 EpochNanoseconds = 2;
}

message Metadata {
	optional string MimeType = 1;
}

My understanding was that this was rejected for... reasons
If this is in fact acceptable - I will re-PR right away ;)

[achingbrain]

Looks good. The capitialisation of EpochSeconds is giving me the twitchy eye, but then so does Type, Data and MimeType. Not that we've been very good at following it but the Protocol Buffers style guide recommends snake_case for multi-word field names.

Do we actually need nanosecond precision or would milliseconds do?

[ribasushi]

The capitialisation of EpochSeconds is giving me the twitchy eye

I was simply following "what's already there"

Do we actually need nanosecond precision or would milliseconds do?

We need to take up 32 bits, at which point the difference between milli and nanosseconds is moot. Also Most of the filesystem supporting fractional times do in fact keep 9 decimal places ( likely for the same 32bit reason )

Ok I am going force-push this entire PR, and we can start over ;)

[ribasushi]

Will open a new PR tomorrow, day got away from me.