From: David Robinson <drobinso@nrg.com.au>
>
> Could someone provide a sketch on the modules/units we'd need and how they
> inter-relate? Then we could start to divide those units down further and
> start implementing units one at a time. These could function as a set of
> seeds. Instead of producing one large project may be we should design a
> set of projects that are interlinked, yet can be developed (almost?) stand
> alone in the traditional open source style. Then a "bake-off" or
> inter-operbility test could be carried out.
That sounds like a good idea.
A module being worked on by a small group is much easier to document and understand then trying to fit the "Big Picture" in all at once.
>
>
> So what so we need?
>
> * a protocol (based on xml?)
> * a storage format ( a database?, a number of files?)
> * a user interface (web browser with intermediary at start?)
> * a means to enter new material
> * a means to retrieve old material
> * a means to find the material that we're interested in
>
This brings up the question:
How do we want to store the information?
Things get very complicated when everything is being stored in one BIG database.
If things can be distributed over many databases in many locations but all interrelated one failure doesn't mean everyone looses out. Each module or NIC could be a database.
We should use a TOP level Directory Like NDS (Novells Directory Database) which allows all databases to know the basics about all other databases so when information needs to be gathered or stored it can use this and contact the correct server quickly. We can create a hugh information repository but keep it manageable as each NIC/database/module/group knows the ins & outs of their system. But may not know how the whole system works and doesn't really need to.
Unlike the web is today where it can take hours to hunt down the correct information, when a user accesses the database and enters a search query for that database/NIC our system can check the Top Level Directory and suggest other areas that the information might be stored.
"A number of files" is going to get slow very quickly, using a Database like Mysql or Postgres would be easier and quicker. Both Mysql and Postgres are free and the source code is downloadable. Besides who's going to design the file format?
In regards to an Interface, XML and HTML and very good for viewing data and searching for data but when it comes to entering data quickly and easily a Web browser just doesn't cut it.
Just look how annoying it can be filling in a form on the web. You fill in this and then that and click Next. Then fill in some more small text boxes and maybe type in a URL or two. And then you realize you made a mistake on the last page and have to click Back, you change it, then you click the Next Button and you've lost all your information from the page you were just worked on.
I believe we have to write our own Interface that perfectly suits what we want to do.
When I'm creating references to other documents I want to just drag that document in or enter its ID tag or category tag so others can easily go off and find out why I came to that conclusion. I don't want to type out 10 URLs which in 6 months time my not exist.
Then at a later date we can add other interfaces to it like the chord keyboard:-)
David Robinson
drobinso@nrg.com.au
--------------------------- ONElist Sponsor ----------------------------
Shop for your Valentine at eGroups.
<a href=" http://clickme.onelist.com/ad/SparksValentine6 ">Click Here</a>
------------------------------------------------------------------------
Community email addresses:
Post message: unrev-II@onelist.com
Subscribe: unrev-II-subscribe@onelist.com
Unsubscribe: unrev-II-unsubscribe@onelist.com
List owner: unrev-II-owner@onelist.com
Shortcut URL to this page:
http://www.onelist.com/community/unrev-II
This archive was generated by hypermail 2.0.0 : Tue Aug 21 2001 - 18:56:44 PDT