Review Comments

who:
re:
comment:

who: backes
re: licensing
comment: any puck licensing hurdles woulc be a disincentive for instrument oems to adopt the puck


who: headley
re: puck download speed
comment: 9600 baud is too slow for large payloads

who: johnson
re: instrument interfaces 
comment: what about non-RS232 instruments

who:maffei
re:UUID
comment: why 16 bytes? what about IPV6, others? 
	* need getID command in puck interface
	ID is most attractive part of header

who: chayes
re: puck header
comment: extend header to include organization & more -- metadata history

[ There were quite a few comments about the puck contents...we need to
  communicate clearly that this is a platform dependent convention, not
  an architectural element of the puck
]

who: maffei
re: puck
comment: can you terminal directly to a puck?

who: various
re:puck, metadata
comment: what is justification for close binding? why not put metadata on host?
mclean: on satlantic system, host supplies metadata for 'addresses' on platform
	via lookup table
burch: close binding has been a 'big win' because people make mistakes
chayes: binding is critical; why separate? better to incorporate into new instruments.
	puck is needed for legacy instruments.
backes: keep puck firmware very low level (like a file system) leave contents and 
 	formatting to a higher level.

who: chayes
re: eth vs serial
comment: ethernet instruments will be needed for other platforms; look carefully at 
the implications of eth vs serial

who: raybould et al
re: metadata
comment: how do metadata changes stay in sync (e.g., if someone uses setProperty(), (when) does the change get reflected in the puck?)

[I think that synchronization of metadata changes is a critical issue for CIMT]

chayes: e.g., for adaptive sampling, for sampling rate change, metadata should reflect WHY the sample rate changed

maffei: spec should allow for different modes to allow changes w/o power cycling the puck.

who: burch
re: puck erasing
comment: why bulk erase? seems useful to be able to have finer control of contents
[ more like a file system ]

who: massion
re: language dependence
comment: how much difference does language make

[ we need to drive home the point that the puck contents and structure are completely
  a platform dependent convention; even maffei's written comments suggest that this
  is not yet entirely clear. Mike's demo idea might do this
]

who: maffei
re: puck timeout
comment: it might be a good idea for the puck to have a timeout, after which time it
would switch to instrument mode
[ yeah! that is a good idea ]

who: backes
re: puck command format
comment: good idea to use (e.g.) puck_cmd format for puck commands to reduce namespace
	collisions with instrument command sets

who: burch
re: standards development
comment: keep physical spec separate from policy and software specs. Take an incremental, layered approach that makes it easy for vendors to comply at lowest level (shoot for 100% compliance at lowest level).


who: burch
re:puck
comment: 
	how about a read-only implementation?
	what about puck primitives to write specific areas?
	Agilent using XML to pass argument arrays

who: burch
re: tool chain
comment: Eclipse, TogetherSoft, JUnit good tools. UML has been a success for them

who: mcclean
re: device discovery
comment: have we looked at Juxta?

who: burch 
re: JMS, pub-sub vs cli-svr
comment: pub-sub has been successful and has advantages over cli-svr in their application
	they use a 'lite' version of a JMS mechanism

who:?
re:scheduling
comment: can we support absolute start point, and relative sample schedule

who: chayes
re: metadata standards
comment: FGDC has well established protocols for metadata; 
	we (SSDS) will need to deal with it.

who: burch
re: metadata
comment: how to deal with floating point numbers in ASCII (XML)

who: burch
re: RMI, bandwidth
comment: very concerned about using RMI over low bandwidth links; 
	what about an 'everything' proxy on shore?

who: godin
re: scheduler gui, code development
comment: Hobilabs has DASHost and scriptWizard (download from hobiLabs)

who: burch
re: thread management
comment: look out for deadlocks, race conditions; ordering of locks is important.
	different programmers may use different call chains for locking, unlocking.
	consider using a watchdog process to detect deadlock.
	using global mutex is effective, but defeats multi-threading.

who:?
re: ethernet on twisted pair
comment: can 10baseT run 1 km?

who: roman
re: networking
comment: keep DHCP leases alive each time node contacts shore. If lease expires,
	it is safe to assume that node is off line.

who: all
re: summary comments
comment:

mcclean: is complex for fully operational system; may be difficult for scientists to
	use instruments routinely. Think about ethernet instruments. Where should the
	smarts for the system be?

chayes: need to look soon at issues re cabled vs non-cabled architectures and what
	are the needs of the cabled observatory community.

chave: Java might be insurmountable hurdle for scientists. (C might be better)


burch: weak link for moored system: RF link; need will always expand to fill capacity