Yann's Blog - Software and hardware

Work is progressing well on an interim release of IRM, to be called 1.6, from the original code base.. This is where most of my development time has been going these past two weeks. This is an effort to provide useful fixes and functionality now, instead of in “the future”. But working on it, despite many fixes from contributors such as Matt Palmer and Martin Stevens, is like trying to tame a beast. But at least we’re making progress

Feel free to hop on the irm-devel mailing list in order to check out current work, or look at the regulary updated Demo: http://www.stackworks.net/irmdemo/demo/

Login in Tech with the password tech (this is case dependent).

Basic Schema Editor support is now available in IRM 2. Making very good progress so far. Next up will be asset management routines! I’ve been busy migrating servers and trying to squash some IRM 1.6 related bugs. More active work should pick up by next weekend.

Been busy with server migrations. I’m moving from a dedicated server to a much beefier co-located server, and its taking awhile to get all the databases and setups transfered correctly.

Bear with me.

I get the occasional question about someone’s browser being seemingly stuck in “IGB” mode. Usually, its not actually stuck, the user was simply expecting some more graphical pizzaz out of EVE-Central.com.

So, why is the interface so bland? Maintainability is the primary reason. The EVE-Online in game browser is a rather buggy, slow, and temperamental beast.  CSS support is worse than Netscape 4, and performance is akin to a Pentium 66 rendering a huge table – it just can’t do it without a week long crunch. Hence all of the market information is limited (only 10 entries or so per table, etc) and no stylesheets or other fun stuff is used.

So why is the main, non-IGB interface so bland too? Primarily for not having to maintain two sets of templates and remembering to update both to fix something or enhance something.

Is it me being somewhat lazy? Yes, of course . I’ve had some contributions for new designs, which come in all sorts of nice colors and DIVs and Javascript – but didn’t really enhance the datamining aspects of EVEC.

We’ll just call the look the Google 1.0 look and work on adding newer features.

Storeables, Schemas, Assets, Storage, CrossReferences: these are all fundamental concepts in the IRM 2. This post is designed to explain some of these key concepts, though the technical verbage here will get somewhat heavy.

Storeable

 Internally, Storeable is simply an interface in IRM 2. It represents no actual object. Storeable objects are special though, they can contain a reference to a Storage subset, which can augment which fields they provide based upon a pre-defined schema. This is a change from the previous IRM 2 view, where a storage entity was an inherited trait. Aggregation simply makes more sense here.

The interface for Storeable exists to  mark classes which have support for Storage containers and provide a common API for accessing them.

Schema

A Schema is a set of fields which exist in every storeage container which utilizes it. Schemas are associated to a type (for instance, Asset), have a name (i.e., “Computer”, “Printer”, “Widget”) and can define fields such as: String name, Decimal purchasePrice, Date purchaseDate.  These can be configured on the fly at runtime, and have limited support for editing (to prevent you from throwing data out of the window ).

Storage

A storage type presents an interface which maintains actual copies of fields specified by a Schema. There is one storage type per higher-type, such as an Asset. Storage is aggregated into the higher type – not by inheritance.

Asset

Asset is an example of a higher-order part. An Asset is just that, a customizable container which can contain a storage entity backed by a Schema. Assets have a complete user interface around them to make managing Assets easier. Another example of a higher order type is Location, and User (user can only have a single schema assigned to it at this time though). These higher order types can also define their own internal fields and methods which can not be altered by a Schema.

CRI

If you were following Python IRM 2 development, you would notice a core concept of GUID, or the Globally Unique IDentifier. GUID was somewhat over-reaching in that implementation, including odd type-promotion and other strange dynamic feature, and also depended on inheritance, which made them somewhat cumbersome to use. IRM 2 Mk III uses CRI, or Cross Reference Identifier, which is aggregated into types which can benefit from its services (though not using IOC concepts such as Inject, yet anyway). CRIs can be associated as before, allowing a graph of associations (Asset contained in Location, owned by User, etc).