Jip Discussion Page
This page is for discussing the Jip (Jamund/Iain/Peter) project. If you have any features you would like to see please put them on the JipWishList not here.
If you modify this page we request that you sign your comments.
Please add any thing, dont take anything off, but write below the item if yoy find a problem with it.
Stored Data
- Project Index (JDBC?)
- Project Data stored on server side (JDBC?)
- Project Data stored on a client computer (XML, any objections?)
- I don't feel that this is absolutely necessary. The developers probably know the status of the projects they are working on as well as all the important information they need. I think this database is more to allow us to see what the others are up to and whether or not they are still working on their projects. -- IL (05-02-99)
- The reason is so when they update data with their client, they can just work with their old project data, and change it, otherwise each time they went to update they would have to re-type their project name and the description, it is just simpler to have the data be stored on their computer.
Viewable Data
- Project List (with basic info)
- Specific Project Page (more info)
UIs
- Web-based (applet and/or html?)
- App-based (Java Swing?)
Other things
- Administering list of projects
- Editing a project
-- JamundFerguson (05-02-99)
- Developers should take care of uploading their own files to their own webpages. The database should simply note where the source/binaries are and should (perhaps) chronicle the revisions (although that too should be dealt with by the developer ... or _the_ CVS _server_) -- IL (05-02-99)
- As I said, I don't think we should be responsible for any files uploaded although I agree the we should use a database for the project data. -- IL (05-02-99)
- What exactly is the "JosProjectClient"? If we store information in XML format, and it gets sent to the server like that, then how do we display it to the client? -- IL (05-02-99)
* OK I just said JosProjectClient meaning whatever client is used by someone that owns a project to update data on the project list. So it should be an interface or abstract class that has general definitions, because things work differently in an app as opposed to an applet. -- JF (05-02-99)
- The client will send the server some XML data which it will parse and stick in a database. (I already have some Perl scripts I made that can do this, I however know nothing of how to port them to Java using JDBC or whatever.)
- Once this data is parsed and placed in the database, how will we generate HTML pages from that data? -- IL (05-02-99)
- We can use servlets for this... I know that people were saying that we can't use servlets, but if the Perl version is well-received we could probably get them to add servlet and database support.
- When I suggested using applets I meant that we can use an applet as a hook to load the database (with a sort of "Database db = (Database) (new ObjectInputStream( new FileInputStream( this.getCodebase() + "db.ser" ) ) ).readObject();"). The webpage and the applet can then communicate using LiveConnect. The reason I propose this is it allows us to make a database with open hooks which can easily be integrated with Peter's GUI but which can also be used in a web-based environment. -- IL (05-02-99)
- When a visitor access the project list page, it should generate a new page based on the database, instead of having to update the HTML each time it is updated or use an applet to interface between the database. The advantages are obvious. Choosing the right technology to update the pages 'on-the-fly' is an issue. The page I am setting up uses perl to do something similar, but I think we can find a more Java orientated solution, servlets? Java Server Pages?
- I agree that the method of delivery is an issue and I like the servlet idea because if the database is designed to work with a web-page and a GUI, we can easily get a Servlet to fiddle with the data and spit out a cool page. I'll ask MarkusPeter about a servlet runner. -- IL (05-02-99)
-- JamundFerguson (05-02-99)
We need a standard way to store data, as far as I know it is all text data. What about possibly storing it in an XML format? Or maybe storing the data on the clients computers (about his/her project) in some XML format, and then storing it on the server side in a database with JDBC? Just a though, I don't really have any compelling reasons for doing this way, but I think it sounds good, and maybe if we had a proposition it could be implemented in the near future.
- I agree that we need a way to store data. Why not simply serialize and jar everything? We could have a Projects.jar file on jos.org somewhere. XML would be a good alternative though and maybe we could use Jade or some such thing to convert our database to HTML if it gets stored as XML. I would prefer the former though. -- IainLowe (04-02-99)
- I don't particularly like the idea of using a server-side technology when we can use applets to update the files on the server and to interact with the client at the same time. I think we already have a good thing going. -- IainLowe (04-02-99)
- I think we should have a web-based interface first and foremost. We can use LiveConnect to pass data from the web page to the applet so at first we don't even need a fancy GUI. Once Peter finishes up however we can move the project to its full and glorious graphic self with both an optional Java App front end and a web-based applet -- IainLowe (04-02-99)
Well, I pretty much agree with everything said above, except that
I don't think it is necessary to store the data in XML locally on
the client side (unless different applications will want access
that same data). Sending the data to the server in XML, on the other
hand, sounds good.
As for LiveConnect, I'll hold off commenting until I know
what it is :)
-- PeterSchuller
Lets store it in XML on the client side, so won't have to transform it on the way to the server.
The data stored on there will just be used by the client to remember the persons last data, so they can just change the old data, instead of re-writing it all of the time.
The reason for saving it in XML, is that it will just be simpler for us to create more than one client, or if we make a JosControlPanel as well as the JIP thing, it will be better to have a standard data format.
Also pushing XML data to a database is pretty easy, and we could create a way to do it that could be used for more than this small project.
- JamundFerguson
As for uploading, I was confusing this with a more general Jos Control Panel or something of that nature.
And what about liveconnect? I don't know one thing about it, but would prefer using a more standard approach.
I am going to get rid of some of my old comments, feel free to do the same, to clear stuff up...
Okay...
- LiveConnect is Javascript talking to Java. It allows us to call Java methods directly from a web-page without having a GUI applet. We can save the GUI for Peter's stuff.
- Is live connect free and cross-compatible, I know there are JavaScript compatibility issues.
- The reason I have a problem with using XML is that in order to use it we need parsers and validators, etc... and I feel that that would be over-complicating the issue. We need something simple and extensible. If we design this correctly (yet simply) to begin with we can always make it more complex later. I would like to propose that we get something running in plain text first and then discuss porting the whole thing to XML as a data storage format. Maybe once we get Apache installed somewhere, we can set up Jade to work with it and then we can serve the XML documents directly to the web-based client. In the meantime however I feel that using XML is a slight case of overkill given that we should IMHO be trying to get this project up and running as quickly as possible.
- I still think that XML should be used for the storing of client-side data, and as the format that the server recieves. I think that the Perl script, when finished will buy us plenty of time to implement this, however if no one else wants to use XML, I'll shut-up.
- What does everyone else think? Debate is if XML should be used on the client side to store data about someones project, and also as the format for the server to recieve data as.
About XML again. The reason I was reluctant to use XML on the client
is that, as (someone, who?) pointed out above, that would need
a parser, which, even though it's no big deal if we limit ourselves
to whatever functionallity is needed for this project,
still requires more coding than just senind the data in XML.
I don't know the specifics on XML, but I've got the impression
it's pretty good, and I don't have anything against it per se.
Just wanted to clear that up, in case I sounded somewhat unwilling
to co-operate last time :)
-- PeterSchuller
Content of these pages are owned and copyrighted by the poster.
|
Hosted by:
|
|