javacavemaps-developers Mailing List for Java Cave Maps (Page 6)
Status: Pre-Alpha
Brought to you by:
caverdude
Menu
▾
▴
javacavemaps-developers — Will be talk about packages, public classes and public methods
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(7) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(39) |
| 2009 |
Jan
(79) |
Feb
(26) |
Mar
(8) |
Apr
(6) |
May
(4) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2010 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Larry G. <jav...@ya...> - 2008-12-29 14:17:24
|
Well, I was refereing to some simple tabular data for a set of survey lines. We are using swing, I suppose a JTable would work fine for this idea. Also I guess we can add a menu bar to an applet as well right? Though it seems strange to me to give an applet a menu bar. I was also refering to working around the sand box limitations by allowing them to cut and paste this data. Larry Gray la...@ar... ________________________________ From: sean wagner <wa...@ya...> To: jav...@li...; Larry Gray <jav...@ya...> Sent: Monday, December 29, 2008 12:22:33 AM Subject: Re: [Javacavemaps-developers] applet and webstart data Not sure exactly what data you are referring to but a quick way to persist data I use is just the native Java serialization. You can write a bean directly to file without having to make a custom XML parser. It is also easily zippable and has a small file size. Catch is you can't manipulate this data manually, also some changes to the bean's class can make legacy persisted beans unreadable. --- On Fri, 12/26/08, Larry Gray <jav...@ya...> wrote: From: Larry Gray <jav...@ya...> Subject: [Javacavemaps-developers] applet and webstart data To: jav...@li... Date: Friday, December 26, 2008, 6:01 PM One thing I had thought of doing was providing a way for the user to save the data somehow on his local hard drive via cut and paste. I.e. we provide an edit box with the xml or delimited data in it for them to do a ctrl-A then copy paste to notepad. And then they can later copy paste it back into the applet or webstart app. Seems lame but its a way to get around the sand box or use of policy files. Anyone have any other good suggestions? Larry Gray la...@ar... ------------------------------------------------------------------------------ _______________________________________________ Javacavemaps-developers mailing list Jav...@li... https://lists.sourceforge.net/lists/listinfo/javacavemaps-developers |
|
From: sean w. <wa...@ya...> - 2008-12-29 06:44:59
|
Just my opinion on the cowboy coding with additional features and etc. If you do a lot of it right you can give people "sand box" areas to which they can play without affecting other portions of the code. That or they can branch, whether their branch is merged into the trunk should be completely up to the project managers digression. Gotta remember that people here are working for free though, and if you want them to stay, you will have to let them do a lot of things that they want to do, cus after all that is why they are here because they want to be. Hell we let people spend at least 25% of their time at work pursueing interests of this sort... and they are getting paid for it.
--- On Sun, 12/28/08, Larry Gray <jav...@ya...> wrote:
From: Larry Gray <jav...@ya...>
Subject: [Javacavemaps-developers] my style
To: jav...@li...
Date: Sunday, December 28, 2008, 7:31 PM
If anyone on the project can't stand the XP methodology, please feel free to remove yourself from the project if you think you can't contribute because of it. I'd as soon see no one in the member list than to see members who simply don't want to help out because of the decisions I make. I realize methodology can be something like Religion to some folks. I'm not religious per say about this XP methodology. But I see some good ideas there. Most developers I think want to start the project out by packing many features and advanced features and they want freedom to work ahead on uneeded features. etc. cowboy coding I guess you might say. XP is a fairly limiting style. You only do what is currently within you capability meaning (time/resources/quality/scope). A
itteration is 2 to 3 weeks, its just for goal setting. We would have several itterations inbetween minor versions. and several minor releases or more up to maybe 10 between major releases and version changes. You can always work ahead on your local computer and have something ready to contribute when the time comes. I am going to try to keep the specs worked ahead as much as possible so we can all know whats coming up next.
I guess idealy we should have one or two task for each person per itteration maybe. Anyway if we are coding we are getting something done. If we don't communicate we can't colaborate. Let me know what your thoughts are other than.. "hi, I'm here to help, I see your an idiot so I'm here to take over, o I can't so sorry. bye now"
Larry Gray
la...@ar...
------------------------------------------------------------------------------
_______________________________________________
Javacavemaps-developers mailing list
Jav...@li...
https://lists.sourceforge.net/lists/listinfo/javacavemaps-developers
|
|
From: sean w. <wa...@ya...> - 2008-12-29 06:39:41
|
I read a book on extreme programming. I personally think the pair programming is overkill. Having multiple people agree on an API then one person code then a different person write the test cases works well. As long as the higher level API is defined right and then tested for the agreed functionality you are set, but code reviews are good. That is about as good as I have ever gotten it, otherwise your just doing everything twice.
I would agree with most of the planning of the XP methodology.
The design part of the XP method I would have some disagreements on though. I don't always think starting with the simplest solution is always the answer. I have had to write and rewrite many systems because the original solution was not extensible enough to support the incoming feature requests. Instead my opinion is to start with the simplest solution possible that doesn't sacrifice the possibility of extension in the future. For example their are certian groundlaying things I will do in most all of my applications. Alot of it just comes down to good OOP principals as well though. You should also be wary of rushing development without enough active planning.
~Sean
--- On Sun, 12/28/08, Larry Gray <jav...@ya...> wrote:
From: Larry Gray <jav...@ya...>
Subject: [Javacavemaps-developers] my style
To: jav...@li...
Date: Sunday, December 28, 2008, 7:31 PM
If anyone on the project can't stand the XP methodology, please feel free to remove yourself from the project if you think you can't contribute because of it. I'd as soon see no one in the member list than to see members who simply don't want to help out because of the decisions I make. I realize methodology can be something like Religion to some folks. I'm not religious per say about this XP methodology. But I see some good ideas there. Most developers I think want to start the project out by packing many features and advanced features and they want freedom to work ahead on uneeded features. etc. cowboy coding I guess you might say. XP is a fairly limiting style. You only do what is currently within you capability meaning (time/resources/quality/scope). A
itteration is 2 to 3 weeks, its just for goal setting. We would have several itterations inbetween minor versions. and several minor releases or more up to maybe 10 between major releases and version changes. You can always work ahead on your local computer and have something ready to contribute when the time comes. I am going to try to keep the specs worked ahead as much as possible so we can all know whats coming up next.
I guess idealy we should have one or two task for each person per itteration maybe. Anyway if we are coding we are getting something done. If we don't communicate we can't colaborate. Let me know what your thoughts are other than.. "hi, I'm here to help, I see your an idiot so I'm here to take over, o I can't so sorry. bye now"
Larry Gray
la...@ar...
------------------------------------------------------------------------------
_______________________________________________
Javacavemaps-developers mailing list
Jav...@li...
https://lists.sourceforge.net/lists/listinfo/javacavemaps-developers
|
|
From: sean w. <wa...@ya...> - 2008-12-29 06:22:35
|
Not sure exactly what data you are referring to but a quick way to persist data I use is just the native Java serialization. You can write a bean directly to file without having to make a custom XML parser. It is also easily zippable and has a small file size. Catch is you can't manipulate this data manually, also some changes to the bean's class can make legacy persisted beans unreadable.
--- On Fri, 12/26/08, Larry Gray <jav...@ya...> wrote:
From: Larry Gray <jav...@ya...>
Subject: [Javacavemaps-developers] applet and webstart data
To: jav...@li...
Date: Friday, December 26, 2008, 6:01 PM
One thing I had thought of doing was providing a way for the user to save the data somehow on his local hard drive via cut and paste. I.e. we provide an edit box with the xml or delimited data in it for them to do a ctrl-A then copy paste to notepad. And then they can later copy paste it back into the applet or webstart app. Seems lame but its a way to get around the sand box or use of policy files. Anyone have any other good suggestions?
Larry Gray
la...@ar...
------------------------------------------------------------------------------
_______________________________________________
Javacavemaps-developers mailing list
Jav...@li...
https://lists.sourceforge.net/lists/listinfo/javacavemaps-developers
|
|
From: Larry G. <jav...@ya...> - 2008-12-29 02:31:33
|
If anyone on the project can't stand the XP methodology, please feel free to remove yourself from the project if you think you can't contribute because of it. I'd as soon see no one in the member list than to see members who simply don't want to help out because of the decisions I make. I realize methodology can be something like Religion to some folks. I'm not religious per say about this XP methodology. But I see some good ideas there. Most developers I think want to start the project out by packing many features and advanced features and they want freedom to work ahead on uneeded features. etc. cowboy coding I guess you might say. XP is a fairly limiting style. You only do what is currently within you capability meaning (time/resources/quality/scope). A itteration is 2 to 3 weeks, its just for goal setting. We would have several itterations inbetween minor versions. and several minor releases or more up to maybe 10 between major releases and
version changes. You can always work ahead on your local computer and have something ready to contribute when the time comes. I am going to try to keep the specs worked ahead as much as possible so we can all know whats coming up next.
I guess idealy we should have one or two task for each person per itteration maybe. Anyway if we are coding we are getting something done. If we don't communicate we can't colaborate. Let me know what your thoughts are other than.. "hi, I'm here to help, I see your an idiot so I'm here to take over, o I can't so sorry. bye now"
Larry Gray
la...@ar...
|
|
From: Larry G. <jav...@ya...> - 2008-12-29 00:23:51
|
Under XP methodology their is this notion of pair programming where one guy codes the other looks up info, runs test and otherwise makes suggestions. One drives the other navigates. We could do something similar to this if you get with someone who is assigned a task and agree to use email, or better yet a messenger client or better yet even IRC (Internet Relay Chat) www.mirc.com for a windows client. typically for this to work out both should be online at the same time working on the same part of the project at the same time. I'm just suggesting that whoever wants to try this, do so. Larry Gray la...@ar... |
|
From: Timothy S. <tim...@gm...> - 2008-12-28 03:41:53
|
Seems like a good temporary fix, but we might want to come up with something more long term at some point. Tim Sprague tim...@gm... On Fri, Dec 26, 2008 at 8:01 PM, Larry Gray <jav...@ya...> wrote: > One thing I had thought of doing was providing a way for the user to save > the data somehow on his local hard drive via cut and paste. I.e. we provide > an edit box with the xml or delimited data in it for them to do a ctrl-A > then copy paste to notepad. And then they can later copy paste it back > into the applet or webstart app. Seems lame but its a way to get around the > sand box or use of policy files. Anyone have any other good suggestions? > > Larry Gray > la...@ar... > > > > ------------------------------------------------------------------------------ > > _______________________________________________ > Javacavemaps-developers mailing list > Jav...@li... > https://lists.sourceforge.net/lists/listinfo/javacavemaps-developers > > |
|
From: Larry G. <jav...@ya...> - 2008-12-27 03:29:15
|
:) guess I forgot it was Christmas. Anyway its not a version release every 2 or 3 weeks but completion of a cycle called an iteration. I guess I need to work some more on the specifications. I did update the Specs for the Survey Analyzer. Seems like I added a little to the other one as well.
Larry Gray
la...@ar...
________________________________
From: "tim...@gm..." <tim...@gm...>
To: jav...@li...
Sent: Friday, December 26, 2008 9:07:14 PM
Subject: Re: [Javacavemaps-developers] need some more communications..
The enthusiasm is great, however it is Christmas so multiple messages in one day asking for more communications seems a bit over the top. Also your expectations of a version every 2 to 3 weeks seems a bit ridiculous at this point. I suggest slowing down getting a nice spec and idea of what this thing should be. I looked at the spec and the existing code and honestly no idea what the UI for this thing should look like or what it should do. Maybe its me and that is fine too.
2cents
Tim
On Dec 26, 2008 3:03pm, Larry Gray <jav...@ya...> wrote:
> I'm holding back on coding myself to hear from you guys. Volunteer for some task. If the task is unassigned see if you can assign yourself to it. Or email me with the task number. If you have further questions about the task, please email me. [time][resources][quality][scope]. Lately I have added about 15 developers to the project. Also I added another caver that is also a Java programmer. So we now have upped the resources (developers) we should be able to up the scope rapidly. As most of you know scope means scale. Or in other words the size of the work load based on chosen features. I have much more to do than coding since I'm managing the project. I'm also the one writing the specs and wiki and making up task. It may take you some time to get used to the iteration
> idea. We should be moving through the ?.1 ?.2 ?.3 ?.4 versions about once every 2 to 3 weeks. On major milestone's we will make release files for download. Meaning 1.0 2.0 3.0 4.0 versions.
>
> Larry Gray
> la...@ar...
>
>
>
>
>
>
>
>
>
|
|
From: Larry G. <jav...@ya...> - 2008-12-27 03:21:51
|
I have made some changes to the source. I now have a bootstrap main method on the command panel. I will next make the thing functional as a calculator. I may move the stat labels to another panel later.
Larry Gray
la...@ar...
|
|
From: <tim...@gm...> - 2008-12-27 03:07:24
|
The enthusiasm is great, however it is Christmas so multiple messages in one day asking for more communications seems a bit over the top. Also your expectations of a version every 2 to 3 weeks seems a bit ridiculous at this point. I suggest slowing down getting a nice spec and idea of what this thing should be. I looked at the spec and the existing code and honestly no idea what the UI for this thing should look like or what it should do. Maybe its me and that is fine too. 2cents Tim On Dec 26, 2008 3:03pm, Larry Gray <jav...@ya...> wrote: > I'm holding back on coding myself to hear from you guys. Volunteer for some task. If the task is unassigned see if you can assign yourself to it. Or email me with the task number. If you have further questions about the task, please email me. [time][resources][quality][scope]. Lately I have added about 15 developers to the project. Also I added another caver that is also a Java programmer. So we now have upped the resources (developers) we should be able to up the scope rapidly. As most of you know scope means scale. Or in other words the size of the work load based on chosen features. I have much more to do than coding since I'm managing the project. I'm also the one writing the specs and wiki and making up task. It may take you some time to get used to the iteration > idea. We should be moving through the ?.1 ?.2 ?.3 ?.4 versions about once every 2 to 3 weeks. On major milestone's we will make release files for download. Meaning 1.0 2.0 3.0 4.0 versions. > > Larry Gray > la...@ar... > > > > > > > > > |
|
From: Larry G. <jav...@ya...> - 2008-12-27 01:07:20
|
We need communication or I'm going to be doing all the work it seems. I need thoughts!
Larry Gray
la...@ar...
|
|
From: Larry G. <jav...@ya...> - 2008-12-27 01:01:40
|
One thing I had thought of doing was providing a way for the user to save the data somehow on his local hard drive via cut and paste. I.e. we provide an edit box with the xml or delimited data in it for them to do a ctrl-A then copy paste to notepad. And then they can later copy paste it back into the applet or webstart app. Seems lame but its a way to get around the sand box or use of policy files. Anyone have any other good suggestions?
Larry Gray
la...@ar...
|
|
From: Larry G. <jav...@ya...> - 2008-12-27 00:56:21
|
xml reader writer works fine after I took the home/blah/ out of that file path.
Larry Gray
la...@ar...
|
|
From: Larry G. <jav...@ya...> - 2008-12-26 20:08:07
|
If a task is assigned to me (caverdude) you may volunteer to take it over. i can reassign it to you.
Larry Gray
la...@ar...
|
|
From: Larry G. <jav...@ya...> - 2008-12-26 20:03:42
|
I'm holding back on coding myself to hear from you guys. Volunteer for some task. If the task is unassigned see if you can assign yourself to it. Or email me with the task number. If you have further questions about the task, please email me. [time][resources][quality][scope]. Lately I have added about 15 developers to the project. Also I added another caver that is also a Java programmer. So we now have upped the resources (developers) we should be able to up the scope rapidly. As most of you know scope means scale. Or in other words the size of the work load based on chosen features. I have much more to do than coding since I'm managing the project. I'm also the one writing the specs and wiki and making up task. It may take you some time to get used to the iteration idea. We should be moving through the ?.1 ?.2 ?.3 ?.4 versions about once every 2 to 3 weeks. On major milestone's we will make release files for download. Meaning 1.0 2.0 3.0 4.0
versions.
Larry Gray
la...@ar...
|
|
From: Larry G. <jav...@ya...> - 2008-12-26 00:55:56
|
I have made some changes to the models mainly. I simplified them for the calculator app. If someone wanted to work on a simple applet to displaying the LinePlanViewPanel and a web start app to do the same that would be the next step. I have begun the application as LineAnalysisUI.
I will continue to work on the "View" as it were. "Controller" coding will begin soon as well. Obviously for the simplest version of this calculator the Models are very adequate. A survey line will then be a SurveyLineModel which contains data plus two SurveyStationModel's.
The math will begin to be more intensive very soon. with a single line we can calculate quite a few stats. For example, ceiling height at station, path width at station. From station to station. Plan view area, and Profile View area. Volume from station to station. So you see our little line analyzer will be slightly interesting in the end. The line analyzer will continue to be part of the software as we progress. At some point the applet and webstart apps may be finished or specialized yet we would continue improve the application. For example the database work. All 3 will handle stats and graphics however.
Larry Gray
la...@ar...
|
|
From: Larry G. <jav...@ya...> - 2008-12-25 23:06:41
|
Ok I've reviewed tiger features, the only things I might have trouble with are Generics and I have not really looked at the new multithreading features much. The rest of it looks fun though. Maybe we can keep the use of Generics simple for a while.
Larry Gray
la...@ar...
|
|
From: Larry G. <jav...@ya...> - 2008-12-25 00:34:05
|
Ya, the guy who runs Arkansas state cave survey has his cave database on a computer in his basement. It is to never be connected to a network or the internet. This guy is also a retired lawyer and he is rich enough to have a very good security system on his house. He has been asked by people wanting to write books about caves in Arkansas and totally rejected them.
Larry Gray
la...@ar...
|
|
From: Larry G. <jav...@ya...> - 2008-12-25 00:20:54
|
Let me explain, cave data for the purpose of surveying and mapping is not such a big deal.. Oddly sharing maps and information that would give away cave locations are a huge controversy. Oh yes, shunning, alienation, should I mention threats to bodily harm or even death threats might be part of this caver soap opera?
Larry Gray
la...@ar...
|
|
From: Larry G. <jav...@ya...> - 2008-12-25 00:13:57
|
By datamodel I usually mean a class that wraps up the data. I guess you meant the xml format? The specs explain what data is to be manipulated.
Larry Gray
la...@ar...
________________________________
From: David Days <da...@is...>
To: jav...@li...
Sent: Wednesday, December 24, 2008 12:19:32 PM
Subject: [Javacavemaps-developers] Data models?
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
|
|
From: Larry G. <jav...@ya...> - 2008-12-24 23:51:45
|
First let me say, I do like XML and want to use it for the main type of storage until we get to the heave database work. I hope someone here is better at making DTD's than I am. I can help with some specifications for the xml files. About CVS, flat file (fixed width), and delimited(as in pipe). These are so common I feel we should keep some classes in the project for loading tabular data from them and write tabular data back to them. These are common types for exporting and importing especially from spread sheets. Cavers have learned how to use the spread sheet well for their purposes. I'm absoultely sure there is lots of data on cave surveys in spreadsheets around the world. This is trivial but Hypersonic SQL (hsqldb.sourceforge.net I think) now allows you to link a flat file, delimited file or cvs file as a database table. Later we may get into keeping database information on caves, i.e. location, type, cave life, cave formations, and much more. This will become database intensive and as there are many "Cave Surveys" around, they probably all use a Database of some kind. The Arkansas Cave Survey uses for example DBase. Since we will be coding JDBC the use of Hypersonic is not such a big deal. Its just that I like Hypersonic because its also written in Java. Now we have opened a can of worms. Someone mentioned Client Server coding which would be for the purpose of colaboration amongst cavers. This will be a last consideration after we have done everything else we can do with this project. The design of this software will be oriented towards individual use. I mean the applet calculator is not such a big deal but anything more that keeps track of data will be. There is much controversy amongst cavers reguarding the conservation of caves. It is generally felt in my home state and amongst given circles in other areas of the country that the best way to protect caves is to keep info about them totally secret and only amongst a close nit group of friends. Or give info out on a need to know basis only. Or simply limit the information released to anyone not in the click basically. You would think these groups were like crime families. Anyway, the goal is to prevent crime to and traffic in the caves. Broken formations are of the utmost concern. There is federal law protecting caves. But I have never seen a law enforcement officer at the entrance of one. Ebay was stopped early on from trading cave formations for example. So making a database for colaboration would be like making a fishing database so that everyone in the neighborhood could tell each other about the nicest fishing holes. The wouldnt colborate much if at all. Only certain close nit groups might. Having said that, before anything like this could be developed a ton of though must go into security considerations and features, as well as encryption JUnit will become necessary as this grows some more. Lets not get started on unit testing just yet. I know there are some programmers that believe in letting the test drive the coding. But I prefer to think of testing as the safety net as the project becomes more complex. Larry Gray |
|
From: X. G. R. <ark...@gm...> - 2008-12-24 20:35:16
|
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 > |
|
From: David D. <da...@is...> - 2008-12-24 18:38:11
|
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
|
|
From: Larry G. <jav...@ya...> - 2008-12-24 02:39:07
|
Later we will probably use Log4J, JUnit and Hypersonic SQL(with jdbc)
Even if we use Hypersonic, some of the flat file and xml file io will probably still be needed for imports and exports.
Larry Gray
la...@ar...
|
|
From: X. G. R. <ark...@gm...> - 2008-12-24 02:34:44
|
I just added a first draw of a class that manipulates XML data for the survey. It created the XML Document, saves it to a physicial file and loads the data from the file. It's not implemented as a test case, just a plain class. I first wanted to know opinions on if that is useful enough, and if it is really necesary to Add a JUnit test case(or any other kind). Check the main method in net.sourceforge.javacavemaps.casetest.arkalain.case1.SurveyXMLFile.java. To test it just execute the class as a java application. Thank you, - Xavier Guzmán Robles. |
2 messages has been excluded from this view by a project administrator.
