Ralf Nieuwenhuijsen schrieb: > > 2008/4/15, cboulanger <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>: > > In a future release, some thought should be put into creating a > datasource abstraction API into which all kinds of datasources > (such as > a directly connected SQL database, a couchDB, an XML database such as > eXist or Xindice, etc... ) can be plugged into. > > > Well, a common api would be hard, since there is a strong distiction > between relational "sql" database systems and the document-oriented > database systems. But there could be a common interface to enable > persistence on multi-backends.
You're right, I didn't mean an API which all datasources have to be squeezed into, but more of an interface design for actions and behaviour that all datasource would implement in their own way in order to solve common tasks like authentication, persistence, and databinding of widgets. For example, from a widget databinding perspective, it shouldn't make a difference whether a qx.ui.table.Table's backend is a relational database or a document-centric one. The layer would define what kind of information is passed to the datasource adapter and what structure the data must have that is returned from it to the widget. Each database type excels in different data structure types. For example, both sql and document-centric datasources have a hard time modelling tree structures (i.e., for the TreeVirtual widget), which an XML datasource would be very good at. I don't like SQL much, either, but it probably much faster in huge normalized datasets than a document-centric db could ever be. The kind of data I work with (bibliographic data), however, would be a perfect fit for a document-centric db... > > Together with a decent > cryptographic library, there should be a way of being able to get > rid of > middleware and let the client handle the datasource directly. > > > I am only aware of couchdb that interfaces through restfull http > protocol. Are there any others? eXist does, for example (XML-based db) > Esspecially relational database engines? They all seem to be consumed > by the horrible (by today's standards) design of sql. I don't know of any, but they would be easy to write in PHP if the security part is well-implemented... Cheers, Christian ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone _______________________________________________ qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
