Theoretically, a set of data, once it is coupled with other data, can then be used in numerous ways. Our niche is using data for school evaluation and improvement. Having opened this particular door we can see many more possibilities for new features to help school leaders in their work. School users are suggesting ideas constantly and we already have a list to keep us busy through next year. It doesn't feel terribly logical to suggest that all this new functionality would or could appear under an existing licence for an MIS product, which is why I keep being surprised to see this view expressed in what is a lively, sensible and informative thread.
As to an OSS MIS I wish developers well with this model. I hope too that you will ensure full data integration with what already exisits so that people can mix and match the best of what is available.
Am I correct in thinking your on about releasing a opensource database, which would only be hosted, for a fee, which people\companies could build apps that link into it (for free)?
Sorry, having problems understanding as I keep thinking your re-inventing the wheel. Be interesting to see what you've created and how it compares.
There are APIs and there are APIs. For instance, would it be implemented as a dotNet library or something more arcane/geeky?Quote:
an open access solution
Mmm.. my off-the-cuff multi-tier architecture I didn't bother posting several eons ago in this thread wouldn't do that either.Quote:
There is no direct connection between the GUI and the SQL db.
I guess you have to have been in s/w dev to appreciate this: Smart people who work in s/w can always point at truckloads of stuff that could be done better.. a lot of software has evolved organically, slowly over time which is punctuated by rushed deadlines... you end up with code containing naff compromises, legacy support, new bits patched on that don't really suit the underlying architecture.Quote:
I'm interested in how you think they, a large software company who's being doing it for a number of years, could have done it better.
Again, pleading ignorance, but is SQL (the language) not a perfectly usable database API? Will another API setting above that really help? If the DB is well structured and documented what more do you need to produce your own GUI on to of that?Quote:
The front end is relatively simple stuff. The hard bit, as you point out, is getting that to read and write to and from the db. What you need for that is a tricksy little API which does all the communication for you. There is no direct connection between the GUI and the SQL db.
(note I stopped doing software development a long time ago, my nieve questions above probably highlight way ;))
There is a great deal wrong with the SIMS DB schema. However, a lot of it is completely understandable as it exists as a progressing product, with massive amounts of legacy support requirements. Think of it like OS X Leopard. There is all sorts of legacy support in that OS, such as Rosetta for PPC apps. What Capita needs to be able to do at some time is what Apple did with OS X Snow Leopard, cutting out a good amount of the legacy stuff, and tidying up the system.
This is why, personally, I do all data access with applications via web services of one form of another in my own software now. It means I can change the DB, and the underlying database access code to my hearts content without affecting the applications using it.
@matt40k and tmcd35
I think your points have been addressed quite well in the above posts (thanks, localzuc).
At the end of the day, like Scholarpack, we're just trying to make a difference. The market needs opening out and there needs to be some innovation and competition. Somebody needs to start putting the requirements of schools before those of shareholders. If people don't like what we come up with then I'm sure they won't use it - which is fair enough.
The idea of whether some sort of layer between the DB and the GUI - an Object Relational Mapper (ORM) is best for these types of applications is a debate that has gone on for years.
a) complicating matters more than they need to be
b) gonna slow things down in an application which already lugs large amounts of data about
I can't help thinking abstracting yourself from the db level is only going to end up in pain somewhere down the line...
Quite a detailed article here.
Every single client application will have to rewrite their database interaction code. With ORM, you have a buffer - and as a provider you're able to change the database as much as you wish without affecting the clients.
Imagine if twitter required all its clients to change the way they work fundamentally every time they made any changes? Or facebook? It just wouldn't work. ORM isn't a choice, it is a necessity plain and simple if you want to allow more than 1 client application to connect.