Profile cover photo
Profile photo
Thomas Beale
Vicarious wanderer
Vicarious wanderer

Thomas's interests
Thomas's posts

Post has attachment
Thomas Beale commented on a post on Blogger.
Great post. I have some experience of this game in e-health where we are building an open platform for health records. Now, some implementations of this (its called are fully open source. One company I worked for flirted with OS as well but conversations with potential investors went the same way as you report here. But. In health there is a further wrinkle. The main value is actually in the content (I.e. actual health records) and its privacy, correctness and performance are all mission critical. So there is a potential place for sustainable business in supplying a managed health data service under contract to e.g. hospitals, state health services. The key impediment to such business is that currently content is persisted inside monolithic proprietary products. But there is movement away from this, to detach the data management from any particular hospital information system product. The dinosaurs (big corps) are fiercely resisting, but the data users (health workers, patients) see the great benefits of open platform served data, with a mix of OS and proprietary apps on top. The real challenge isn't to write the software, its to provide a credible health data service. Companies who can prove their ability to do this can indeed sign very healthy contracts. Perhaps some of this can apply to other industries.

Post has attachment
I had an idea for an Eiffel Hub logo. Here's a quick sketch. Someone who can actually do logos might be able to make something of it. #eiffelhub  #eiffel

Sharing Eiffel code and utilities - how do we really do it?

I have cleaned up my 'generic' libraries to a reasonable extent, see . But the whole project is still a single project, even though it contains seemingly disaparate things. 

As you can see from the home page, some of these are:

- a compiler and serialisers for ODIN (Object Data Instance Notation) - the (more powerful and more readable) JSON equivalent we use extensively on the openEHR project. We use this for all .cfg files, object schema files, and general serialisation purposes.

- the msg_code_gen tool to convert error & UI message files into code, so that a) no extra files need to be shipped, b) UI & errors can be localised to any language and c) all such UI elements are converted to Eiffel constants, so that any missing definitions cause a compile fail (i..e you can't accidentally ship your app with missing error cods or UI strings). The input files are in ODIN form. Ideally a tool like this would be integrated into Eiffel Studio to provide proper internationalisation of apps.

- a tool to convert a whole directory tree of .ico & .png files to source code (avoid shipping hundreds of icons). Ideally this would also be in Eiffel Studio.

- the Basic Meta-Model library, essentially a XMI replacement expressed in ODIN, based on the Eiffel meta-model (primarily data elements, no functions yet). We use this to represent object models published as standards (UML diagrams are not computable, except via XMI which is an unholy unreadable mess).

- a rough and ready UI library called EVX that is a layer on top of the EV_* classes, providing a higher level of calls to create controls, menus etc. 

- various app framework classes, that I am sure everyone has their own versions of, and keep being re-invented time and again. Particularly environment settings of all kinds, app defaults, etc.

- various other classes needed to make up for missing features in ISE and gobo classes (simple example a class that provide a file system function to return the full paths of all files defined by a regex, i..e something a bit like find path -name regex -print).

I could in theory separate these out somehow, but actually they are inter-dependent at various levels, a bit like gobo. For example, nearly everything relies on the ODIN parser, e.g. all my apps create, save and read their .cfg files in that form, and also get all their UI strings from ODIN files. And so on...

The test code for all these tools is in various stages of development (our real 'test' is our main archetype workbench application).

Rather than do a lot of separation work on my own, I would rather have a discussion with people here to get an idea of how best to arrange, package, document etc code and tools that are potentially re-usable.

These are the original Eiffel Hub questions. 

I know others are working hard on things like EWF and much else. But I can't help the feeling that we commonly re-invent things and don't share because sharing is too hard.


[One thought I have is this: I used to think in terms of trying to get everything into a single library space, e.g. the ISE shipment. I now think this is a bad idea. It would be better if we just has libs in $ISE_EIFFEL, $GOBO, $EWF, $WHATEVER, but they all worked to the same principles. Tools and libs that are fixes to Eiffel Studio should of course be added there. We need to work out those common priinciples]

- thomas
Wait while more posts are being loaded