[ome-devel] Understanding the 'Big Picture' behind the OME API

[Nick Perry]

Okay, so having read this page (
http://trac.openmicroscopy.org.uk/omero/wiki/OmeroClients?onlycpp) about
1000 times, I'm ready to test if I finally understand what's going on here.
I'm just going to start listing points/concepts, so if anyone can just
confirm/correct as they see fit, that would be extremely helpful. It could
also probably be useful in helping clean up that page since it is rather
confusing (to someone who didn't develop this stuff, anyway).

- ICE provides generic types (primitives, sequences, dictionaries, etc) that
serve as the 'middle-man' for converting between those types between
languages (ie, going from a list in python to a vector in C++, or something
like that via the Ice 'sequence'). The reason for using ICE is so that
people can write client stuff in any of the 4 languages (Python, Java, C++,
Matlab) and everything gets converted the same way. All the information
about the types provided and what they convert to in each language are found
in the slice definitions that can be found here:
https://trac.openmicroscopy.org.uk/omero/browser/trunk/components/blitz/resources/omero

- From the types that ICE provides (primitives, sequences, etc), OME made a
bunch of objects, which are the objects that get passed to and from (along
with the ICE types) the server from the client. However, once these objects
are on the client side (my side) I can cast them back to their native
language. For example, if I have a sequence of objects
(omero::api::IObjectList),
I can cast it back to a vector of those objects in C++ (a vector of
IObjects).

*Question: *Where is the master list of objects? Right now, I guess I can
just check out Image.h to find out about the Image class, but there must be
a list online somewhere?

*Question:* Is Image a subclass of IObject? Similar to how Map is a subclass
of Object in Java (hopefully I'm using my terminology correctly...)

- Every OME object (for example, Image) has a constructor with an 'I' added
(ImageI(), for example) which returns a pointer (ImagePtr) to that object,
all provided by the API library.

- In addition to objects, OME also made a bunch of methods. If i were to
click through each service on
http://trac.openmicroscopy.org.uk/omero/wiki/OmeroApi I would see every
method available to me through the API, and know which category of use it
belongs to.

*Question: *If this is not the case, are all the methods defined here (
http://hudson.openmicroscopy.org.uk/job/OMERO/javadoc/) under ome.api?

- I can use normal C++ types in my code, and ICE handles converting it to
the 'generalized' form when it's compiled that the (Blitz?) server can
understand. The server otherwise doesn't understand just plain C++ types
(especially the ones the other 3 languages don't share). However, sometimes
in my code, like when a method returns an object used by ICE (for example, a
omero::api::IObjectList), i need to write that as what is being returned in
my code. But, I can immediately cast it to vector if I wanted to. So in my
code I can use both the ICE types and c++ types that ICE supports, and
everything will be ok.

*Question: *Will everything be ok..?

- rtypes just give primities in a 'wrapper' that allow them to be NULL. kind
of like how Integer is a wrapper for an int in Java to provide special
benefits.

In summary:

- ICE makes my basic types (in my incorrect vocabulary, my arrays, maps,
ints, floats, etc) (*documentation*:
https://trac.openmicroscopy.org.uk/omero/browser/trunk/components/blitz/resources/omero
)
- OME made objects that utilize the above ICE basic types (*documentation*:
i have no idea)
- OME made methods for the above OME objects and ICE basic types used to
communicate to the server. (*documentation:* maybe at
http://hudson.openmicroscopy.org.uk/job/OMERO/javadoc/)

Thanks for the help
Nick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openmicroscopy.org.uk/pipermail/ome-devel/attachments/20090910/760785c2/attachment-0001.htm