RFC period started for Obscore 1.1 [id, new: widths]

[Markus Demleitner]

On Tue, Jun 21, 2016 at 09:54:00AM -0700, Patrick Dowler wrote:
> I might call that thing #core-1.1 so that if we defined more tables
> they could have their own #symbol.
> 
> eg the ObsFile and ObsPart stuff I showed in Sesto,  or
> 
> eg possibly dataproduct_type-specific tables that could be joined to
> ObsCore, eg ObsCube (#cube-1.2) or ObsTimeSeries (#time-1.3) since
> those were alternative solutions we discussed in the context of
> extending ObsCore for the cube use cases.
> 
> Not saying we would do those, but #core-1.1 seems appropriately specific.

+1 from me on core.

And to keep that from being a pure mee-to, here's one I noticed while
implementing obscore 1.1 in DaCHS:

I'm not a big fan of codifying all the _xel columns as bigint -- why
would you do that?  Leaving aside the issue that I have severe doubts
that we'll see cubes with more than 2e9 pixels any time soon and I'm
totally certain 32 bits will always be enough to keep the number of
polarisation states -- I really think obscore should just say "it's a
floating point type" or "it's an integral type" and say nothing about
the sizes, as they don't matter to clients in any way I can see, and
different services may have different requirements to them (which
applies to columns other than _xel, too, of course -- there's no
reason to require single or double precision either).

With apologies for having noticed this only now,

          Markus