I think that is quite ambitious for a school project, especially over the course of a single semester.
Just to clarify the difference between OMERO and an “ImageJ server”:
OMERO is a full-blown data management platform with many dependencies which (ideally) requires a dedicated sysadmin to install and maintain. The main idea there is that you can have a central place where your lab puts all their data. Analysis functions in OMERO are secondary—it provides a framework for them, but not a full-featured built-in analysis suite.
Conversely, the ImageJ server is (will be) a lightweight stack (built on Dropwizard) with no external dependencies apart from Java, which spins up and down in a matter of seconds. The main idea is to allow for non-Java programs to quickly and easily interface with the ImageJ API regardless of language, and across the network. The ImageJ server will have no support for data storage and management—you’ll still have to figure out where and how to store your images; you could combo it with something like ownCloud, but that would be a separate thing. Or you could of course combo it with OMERO, via the aforementioned ImageJ-OMERO integration. Analysis functions in ImageJ are primary—it is really trying to provide a large suite of image analysis routines, as well as an extensible framework for the community there.
There are several challenges. Primarily:
- On the server side, getting the details of the RESTful endpoints right
For (2), it will be very easy to expose all available ImageJ2 commands in some kind of menu structure/hierarchy. The tricky part is designing a nice 21st century UI that the majority of people find friendly right off the bat, while still providing the shortcuts needed by the power users to get things done efficiently. People have many different schools of thought on what makes a good UI (see e.g. ImageJFX, Icy, BioImageXD and of course the ImageJ 1.x UI).
One other point, regarding Java applets (since you linked to the forum post discussing running ImageJ as an applet): it is becoming increasingly clear that despite Oracle’s efforts, Java applets are a dying technology. Chrome has stopped supporting them. And Java Web Start is not much better. Of course, you could create a web page which launches ImageJ via Java Web Start, but honestly it would be rather crappy usability-wise, and would bring basically nothing to the table from a utility perspective. The client-server approaches I discuss above will be vastly superior, and more future-proof.
Can you tell us more about your focus in school? Is UI design relevant to your studies? Or are you more interested in the image processing side?