Thursday 15 July 04
Right… I think we’ve got it sorted out now! I can create some java code which will act as the interface between the LD Player and the actual tools. The player will then just have a predefined set of methods that can be applied for each tool (search, forum etc). The interface will then be the ‘local environment description’ (LED for short!). That way, if the tool thats needed to provide the service needs to be changed, all that needs updating is the code for the LED, not the whole code for the player… if that makes sense. The tools can then appear to be ‘part of’ the LD Player, ie have the same design/header etc, and the tools can be switched without the user noticing any difference.
On the downside of this, the player will only have a preset number of methods and to take advantage of some whizzy thing that one of the tools does (which isn’t a generic function of the other tools in that category), then both the LD Player and the LED will need updating. However, I think that the ease at which tools can be switched in and out, along with the fact that end users only have one interface whatever the actual tool they’re using behind the scenes, outweighs this disadvantage.
Anyone who knows anything about the OKI OSIDs will probably be thinking – that’s just what OSIDs do, so why aren’t you using that method? Yes, what I’ve descibed is based on the ideas used in OSIDs, but the reason that I haven’t actually used the OSID definitions is mainly because I don’t understand enough about them (!) and for the scope of this project I don’t think I’ll have time to get fully up to speed on it. Also the OKI OSIDs are still in their initial phases and there aren’t many tools around yet compatible with them. However, there should be no reason why a future development of this LD Player shouldn’t be to change to using OSIDs.
