Re: [Javacavemaps-developers] Data models?

[X. G. R. <ark...@gm...>]

I totally agree with using the XML as our data traffic format. We could
always have a central database in a server (for maps of known caves), which
would send the information to whoever requests using an XML file(easily done
with webservices).
Obviously we would need to write this code for the "server" (the one parsing
the information in the database and putting it into an XML).
The xml files would allow an easy and standard way for the clients (be it
computers, phones, or whatever is being used to get the information of a
cave from the server) to read and store well-known caves, and would allow
easy updating of known data in the server(say, someone finds some small
opening in a cave that is not registered yet).

What do you guys think? I suppose we need more people to give opinions

2008/12/24 David Days <da...@is...>

> Hey, all,
>
> I guess I'll start with a question about the stored data model.  Is
> there a plan for the format that the data will be stored in?
>
> --XML is one possibility.  The file format would be human-readable and
> editable (if necessary).  It would also allow the format to be used in
> other applications:  web pages, javascripts, and other mapping software
> would be able to use this format easily.  It would also make the
> application web portable; storage to and retrieval from a server would
> be fairly simple.  It could also be easily changed--just add new data
> tags if there another datapoint to be stored.
>    On the other hand, at lot of up-front work would have to be done to
> figure out the exact tagging and model.  The application would have to
> have a subsystem that handles the IO correctly, and would either
> gracefully fail or ignore XML tags that it doesn't understand (in the
> case of newer versions of the XML being posted.)
>
> --Straight database is another possibility.  Data modeling is pretty
> standard, and the data could be interchanged with other flat-file
> formats.  But the user would have to have a live connection to the
> database to work the application.  One could aways use an internal
> "local" database, such as HSQLDB.
>    That would solve live connection problem, but brings up issues with
> exchanging data with another system--you'd have to come up with a data
> interchange format (even if it is a simple SQL export) that would be
> understood by all.  That would make database changes or upgrades
> difficult--the new database SQL (whatever it may be) might not be
> backwards compatible.
>
> --Straightforward serialized object export.  This is the simplest--tell
> the app to save the serialized CaveModel or StationModel (or whatever
> higher level) into a file.  On the other hand, it would require local
> permissions for a web-enabled application (reading and writing files)
> and, in my experience, leads to dead-end errors if there is a file
> corruption--the data is saved in an unknown format, the program can't
> read it, and all you get is some kind of "unable to load" error.  You
> never know if the file is corrupted, the connection has a problem, or if
> your application is failing.
>
>    My suggestion is to use the XML type as a basis, then write
> "connectors" or SPI (service provider interface)-type backends.  The
> application expects the data as an XML-formatted file.  If it needs to
> connect with a central repository, the repository can _be_ a database,
> but writes out its data in XML format.  This way, you can have an online
> server store the data in a database (with extraneous data like pictures,
> notes, history, etc); this makes publicizing the findings easy with a
> straightforward webapp.  But actual data is interchanged in a known format.
>    Again, the workload is up front; the writeObject() and readObject()
> methods have to be written to both format the XML and "fail" (or skip)
> gracefully if it encounters something weird.  But the payoff is a more
> portable application that doesn't cause follow-on developers to have a
> migraine translating data back and forth.
>
> Just my thoughts.
> David Days
> happyslayer
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Javacavemaps-developers mailing list
> Jav...@li...
> https://lists.sourceforge.net/lists/listinfo/javacavemaps-developers
>