<html>
Hi Stuart,<br><br>
On this side of the pond there has been some interest in standardizing
remote memory/FIFO/mailbox interfaces.<br><br>
Two protocols were developed one a US only another under SpaceWire called
RMAP.&nbsp; While our software people do not mind RMAP the hardware guy's
are saying no because its to complicated.<br><br>
On another front standard access to persistent storage has lead people to
look at &quot;NFS&quot; (like or lite) primitives for remote file
access.&nbsp; Thus commands to open/close, read/write, delete, simple
directory operations.<br><br>
Just some food for thought.<br><br>
Rick<br><br>
<br>
At 07:10 AM 4/26/2005, Stuart Fowell wrote:<br><br>
<blockquote type=cite class=cite cite><font face="Tahoma" size=2 color="#0000FF">Dear
all,</font> <br><br>
<font face="Tahoma" size=2 color="#0000FF">One of the actions from the
Athens meeting was to determine the goal of the File Transfer Service by
1st May. So here's my kick-off of the discussion:<br>
</font><br>
<font face="Tahoma" size=2 color="#0000FF">From my perspective, I see
little scope at the moment for transfer of files between file stores
on-board a spacecraft. How many different file stores are there?<br>
</font><br>
<font face="Tahoma" size=2 color="#0000FF">However, there is the need for
standardised distributed access by applications to some form of
persistent storage. This is more than just a file store, as there are
other mechanisms, e.g.</font>
<font face="Century Gothic, Avant Garde" size=2>FIFO/LIFO structures,
linked lists (including packet stores), File Management System (FMS) for
hierarchical and flat file stores, tape recorder and private partitions
(user-defined format).<br>
</font><br>
<font face="Century Gothic, Avant Garde" size=2>FYI: There are two
parallel studies, funded by ESA, looking into this. Their
&quot;objectives of the project are to define a Data Management Software
architecture suitable to support all the payload and platform
requirements in terms of data storage access for any type of mission,
make the architecture independent from the mass memory technology and
compatible with the COTS software used. In order to be able to cope with
a wide range of project requirements, the system must be configurable and
sizeable in term of capacity, data-rate organisation, interfaces and Mass
Memory technology used. It also have to be reconfigurable in-flight in
order to fulfil mission requirements in terms of availability,
maintainability. Finally, optimisation of its power consumption is
mandatory for future interplanetary missions as well as small satellite
applications.&quot;<br>
</font><br>
<font face="Century Gothic, Avant Garde" size=2>So I propose that we
should set a goal of providing a Persistent Store Access Service. This
can be used as a building block for more format-specific services such as
a File Access and Management Service, for which the file store
requirements in CFDP provide a starting point.<br>
</font><br>
<font face="Tahoma" size=2 color="#0000FF">Stuart</font> <br><br>
&nbsp; </blockquote>
<x-sigsep><p></x-sigsep>
Richard G Schnurr Jr<br>
Chief Architect<br>
Electrical Systems Center<br>
Applied Engineering and Technology Directorate<br>
NASA GSFC Code 560.0<br>
Greenbelt MD 20771<br><br>
(301)-286-1852</html>