[ome-devel] Existing client side code in C

[Joshua Moore]

I'd like to throw a few cents into the "thin layer" idea proposed early
on, but with a twist.

Currently, OME-IS works with simple GET statements like:

    GET http://ome.../cgi-bin/omeis/Method=GetThumb&PixelsID=39

Perhaps we can take this simplicity, add a few extensions, and have a
working REST web service (thereby sidestepping the XML-RPC/SOAP
discussion) for OME-DS. What we'd propose is to provide addressable
locations for each SemanticType. There are a couple of ways of doing
this. E.g.

    GET http://ome...:8080/Attributes/Images/Dimensions/X?PixelsID=39

This would be the call in the Java/Servlet world. (I'll leave Perl/CGI
as an exercise for the reader.) It returns a string which must be
parsed, _but_ the information for how to parse it could be passed in the
header. This means:

    HEAD http://ome...:8080/Attributes/Images/Dimensions/X?PixelsID=39

would return a mime-type or other such metadata to allow a proper
casting of the byte array. We assume that the return would be a string
which would be parsed, but this can be discussed.  Also possible would be:


    GET
http://ome...:8080/Attributes/Images/Dimensions/X?PixelsID=39&ReturnType=XML

to get something more "standard".

All semantic types would be available within a tree. This means:

    GET http://ome...:8080/Attributes/Images/Dimensions/X?PixelsID=39
    GET http://ome...:8080/Attributes/Images/Dimensions/Y?PixelsID=39
    GET http://ome...:8080/Attributes/Images/Dimensions/Z?PixelsID=39

as well as

    GET http://ome...:8080/Attributes/Images/Timepoint/TheT?PixelsID=39
    GET http://ome...:8080/Attributes/Experimenter/LastName?PixelsID=39
    ...

This is our API. It could be quickly listed on a single webpage (dynamic
of course). In this scenario, I'd suggest:

    GET http://ome...:8080/Attributes

If a user adds an id to the GET, then rather then getting a listing of
attributes, s/he could get the actual values:

    GET http://ome...:8080/Attributes?PixelsID=39

Though, this could also be restricted to a sub-tree:

    GET http://ome...:8080/Attributes/Images?PixelsID=39

The return values for such higher-level calls could be name-attribute pairs:

    Dimension.X=64;Dimension.Y=64;Dimension.Z=3;...

Or when dealing with datasets,

    GET http://ome...:8080/Attributes/Images?DatasetID=12

could return:

    PixelID=39:Dimension.X=64;Dimension.Y=64;Dimension.Z=3;
    PixelID=40:Dimension.X=64;Dimension.Y=64;Dimension.Z=3;
    ...

Again, all of this could also be done in XML rather than pairs.


What this means for the C client is that libcurl would suffice for
direct communication with both servers. Then, we could/would/should
prepare a helper layer consisting of the methods from OMEIS
(http://docs.openmicroscopy.org.uk/api/omeis/methods.html) as well as
new ones for OMEDS. I assume for OMEDS we could generate this from the
SemanticTypes.

    getPlane(pixelId,z,c,t)     --> binary octet stream
    ...
    getAttributes(pixelID)      --> name-value pairs or xml
    getImageAttributes(pixelID) --> name-value pairs or xml
    getDimensions(pixelID)      --> ...
    getDimensionX(pixelID)      --> single value
    ...

What the client then does with this information is a, thankfully, left
open. I know for our applications this would suffice, since we have
existing data structures and just need to get some of this stuff packed
in there. If we'd like to go further and produce C++ objects which use
the helper methods which use the REST services, sure. Whatever floats
our boat. But this optional layering lets us get to work now.

thoughts?
- josh.

PS most this really just comes down to naming. If'd you rather see:


http://ome//perl2/serve.pl?Page=OME::Attributes&Type=OME::SemanticType&...

Sure. I think those above are more suited for an API, though.