ObServe is a repository for my own observable classes. I had some different ideas about observables that I decided to implement. See the wiki for more information. Eventually, I also want to write an observable database. About the observable DB:
I had an idea for a backend data layer that I believe would revolutionize how applications are designed and implemented. It's an observable database. That is a database whose application interface is observables. So instead of using result sets and SQL queries/updates, one would construct a query and receive an observable collection. The collection could be filtered/mapped/combined/etc. to serve the application's needs. In addition, filtering/mapping/combination could be done on the backend in the database configuration and this data returned from queries. To update, add, or remove data, a mutable collection would be obtained and manipulated. When data on the backend changes, the observable collections in the applications would update and observers invoked.
The basic idea for configuration is sort of a mix of spreadsheets and database tables. One would define a schema for an application consisting of various writable tables (input) that may have any number of rows of data, each row having an entry in each of the table's columns. Columns would have a name and a type. All this is identical to database tables.
In addition to these writable tables into which an application would pump data, there would be other, read-only, tables that are permutations of the data in these traditional tables or of other views. This is similar to the database concept of a view. Whenever data is added to, removed from, or changed in an input, the data in the views would change accordingly.
Each of these tables would be represented to the application as an observable collection with each element in the collection representing a row. This functionality is theoretically available via trigger mechanisms in some DBMS's, but not in the observable format, which is much easier to write applications against.
These are all the basics of the system. When designing an application, one would design all the input tables, create views that filter, collate, operate on, and otherwise manipulate this input data into sets of data that are represented directly in the GUI with minimal or no application logic outside of the data definition.
As an example, consider a very simple calendar application. We'll have an event table. It would have a date and a name and perhaps some other information. Then an alert table. This table would have a reference to event that the alert is for, the time (or maybe time offset) of the alert, maybe the mechanism of the alert (SMS, email, notification, etc.), and a flag specifying whether the alert has been disseminated. We would create a view that filters the events to be only the current month using a view operation that would be available from a schema creation GUI. Then we have a current alerts view that filters alerts whose alert time is in the past but whose dissemination flag is not set.
The application would have 2 sets of logic. One is to display a layout of the days for the current month, query the current-month-events view, and for each event, place it in the proper day. When a new event is created or the month rolls over, the view's data will change automatically and the application logic would be re-called automatically as a feature of the observable collection. The other piece of logic is to monitor the current-alerts view. For each alert, perform the appropriate dissemination action and set the dissemination flag on the alert.
Adding features to this calendar would be easy. For example, to add the ability to change the month view of the calendar, add an input with a single entry of the selected month. The current-month-events view would be change to filter events whose time is within the value of the selected month. The application needs the user widget to select the month. Done.
I believe defining the application logic in this format would make almost any application very simple to understand. It also lends itself well to displaying application logic in a graphical format. It also lends itself very well to automated tools. In the future, I will develop a Quick sub-project containing widgets or models that interact directly with ObServe. The end goal is to allow developers to build any application, no matter how massive the scope, just by defining tables and writing some Quick files.
Eventually, I want to also develop a server mode, allowing people to define inputs and views and share individual tables with others or with the public. Others could create their own views on this data to perform their own logic on them and use the data in their own applications. Data of any sort could be exported in this way. Protocols could be developed to make this very efficient. In particular, views would not necessarily need to be persisted in the same way as inputs. Views could be calculated dynamically based on their inputs. If a particular column of a view is computationally intensive but spatially small, this column could be persisted and the rest dynamically computed.
One other thing to note is that a universal, bare-bones GUI on top of this framework could be very useful by itself. It could expose and manipulate data in similar ways to spreadsheets but in a more structured and powerful way.
My priority at the moment is Quick. I want to have a well-running minimal set of GUI functionality before I write any code for this project. Ideally I'd like Quick and ObServe to release 1.0.0 at the same time, maybe along with another repository containing a large, useful application that uses both libs and has a minimum of java code in it. Maybe a calendar/task/lists app or a development environment.