<?xml version="1.0" encoding="UTF-8"?><!-- generator="wordpress/2.0.1" -->
<rss version="2.0" 
	xmlns:content="http://purl.org/rss/1.0/modules/content/">
<channel>
	<title>Comments on: Shared Data and Mobile Data</title>
	<link>http://lesscode.org/2005/10/02/shared-data-and-mobile-data/</link>
	<description>AAaaaaahhhhrrrrrrr!</description>
	<pubDate>Mon, 17 Sep 2007 09:12:27 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.0.1</generator>

	<item>
		<title>by: Yes, But What About The Legacy? [@lesscode.org]</title>
		<link>http://lesscode.org/2005/10/02/shared-data-and-mobile-data/#comment-525</link>
		<pubDate>Mon, 03 Oct 2005 21:05:19 +0000</pubDate>
		<guid>http://lesscode.org/2005/10/02/shared-data-and-mobile-data/#comment-525</guid>
					<description>&lt;p&gt;[...] Once again, I need to branch out into a new thread, for the benefit of bringing to everyone&amp;#8217;s attention the importance of the legacy stuff. Here is what Kevin Smith wrote in response to my post Shared Data And Mobile Data: Alex, I completely agree with you, but one big obstacle is legacy stuff: Legacy apps which already have data in rdbms’s. Legacy code. Legacy coding patterns. Legacy frameworks. Traditionally, exchanging data has been quite difficult. [...]&lt;/p&gt;
</description>
		<content:encoded><![CDATA[<p>[&#8230;] Once again, I need to branch out into a new thread, for the benefit of bringing to everyone&#8217;s attention the importance of the legacy stuff. Here is what Kevin Smith wrote in response to my post Shared Data And Mobile Data: Alex, I completely agree with you, but one big obstacle is legacy stuff: Legacy apps which already have data in rdbms’s. Legacy code. Legacy coding patterns. Legacy frameworks. Traditionally, exchanging data has been quite difficult. [&#8230;]</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: Kevin Smith</title>
		<link>http://lesscode.org/2005/10/02/shared-data-and-mobile-data/#comment-522</link>
		<pubDate>Mon, 03 Oct 2005 18:44:06 +0000</pubDate>
		<guid>http://lesscode.org/2005/10/02/shared-data-and-mobile-data/#comment-522</guid>
					<description>&lt;p&gt;Alex, I completely agree with you, but one big obstacle is legacy stuff: Legacy apps which already have data in rdbms's. Legacy code. Legacy coding patterns. Legacy frameworks. Traditionally, exchanging data has been quite difficult.&lt;/p&gt;

&lt;p&gt;Beyond that, if you expose an rdbms today, people can immediately generate useful and productive reports from it. They can query it. With a custom app that is &quot;willing to&quot; exchange data, there's a steeper curve for other apps, and unless you have pre-exposed all your data through published api's, you'll have to keep extending your code to meet the data exchange needs of other apps. So with today's technologies and patterns, there are some immediate benefits of the &quot;data is shared&quot; model.&lt;/p&gt;

&lt;p&gt;Many developers are so immersed in rdbms's that they don't even realize that the concepts of data storage and data exchange are separable. I figure we're at least a few years away from the point that your &quot;data is mobile&quot; idea is widely accepted in by mainstream (especially corporate) developers.&lt;/p&gt;
</description>
		<content:encoded><![CDATA[<p>Alex, I completely agree with you, but one big obstacle is legacy stuff: Legacy apps which already have data in rdbms&#8217;s. Legacy code. Legacy coding patterns. Legacy frameworks. Traditionally, exchanging data has been quite difficult.</p>
<p>Beyond that, if you expose an rdbms today, people can immediately generate useful and productive reports from it. They can query it. With a custom app that is &#8220;willing to&#8221; exchange data, there&#8217;s a steeper curve for other apps, and unless you have pre-exposed all your data through published api&#8217;s, you&#8217;ll have to keep extending your code to meet the data exchange needs of other apps. So with today&#8217;s technologies and patterns, there are some immediate benefits of the &#8220;data is shared&#8221; model.</p>
<p>Many developers are so immersed in rdbms&#8217;s that they don&#8217;t even realize that the concepts of data storage and data exchange are separable. I figure we&#8217;re at least a few years away from the point that your &#8220;data is mobile&#8221; idea is widely accepted in by mainstream (especially corporate) developers.</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: Laurent Szyster</title>
		<link>http://lesscode.org/2005/10/02/shared-data-and-mobile-data/#comment-517</link>
		<pubDate>Sun, 02 Oct 2005 15:41:46 +0000</pubDate>
		<guid>http://lesscode.org/2005/10/02/shared-data-and-mobile-data/#comment-517</guid>
					<description>&lt;p&gt;Your question underscores one characteristic of RDBMS, they are for computer applications, no for network applications.&lt;/p&gt;

&lt;p&gt;Although most RDBMS are today implemented as network servers, they were not designed for network applications. Significantly, data distribution on a network between databases is allways a problem with RDBMS. There are no standard relational database replication protocol and distributing data amongst different databases must be developped as an application in most case, usually with a messaging system.&lt;/p&gt;

&lt;p&gt;So, once &quot;the network is the computer&quot;, RDBMS becomes obsolete.&lt;/p&gt;

&lt;p&gt;For instance the web is a network application made of simple file server and a simple network protocol. Not relational databases. Web applications usually don't use RDBMS to manage most of the data served, instead they serve hypertext from a simple file system.&lt;/p&gt;

&lt;p&gt;People in the industry are however very reluctant to admit the mismatch of relational databases and network applications.&lt;/p&gt;

&lt;p&gt;For instance, RDF stores are actually designed very much like RDBMS, some even are developped &quot;on top&quot; of relational databases. And the latest query language supposed to &quot;light the fire of RDF&quot;, SPARQL, is nothing more a pathetic attempt to provide SQL developers with a familiar face.&lt;/p&gt;

&lt;p&gt;To manage that &quot;shared and mobile data&quot; for network applications, I have designed something completely different:&lt;/p&gt;

&lt;p&gt;http://laurentszyster.be/blog/pns/&lt;/p&gt;

&lt;p&gt;It is a work in progress, but you can allready check it out:&lt;/p&gt;

&lt;p&gt;svn://svn.berlios.de/allegra/trunk&lt;/p&gt;

&lt;p&gt;http://svn.berlios.de/wsvn/allegra&lt;/p&gt;
</description>
		<content:encoded><![CDATA[<p>Your question underscores one characteristic of RDBMS, they are for computer applications, no for network applications.</p>
<p>Although most RDBMS are today implemented as network servers, they were not designed for network applications. Significantly, data distribution on a network between databases is allways a problem with RDBMS. There are no standard relational database replication protocol and distributing data amongst different databases must be developped as an application in most case, usually with a messaging system.</p>
<p>So, once &#8220;the network is the computer&#8221;, RDBMS becomes obsolete.</p>
<p>For instance the web is a network application made of simple file server and a simple network protocol. Not relational databases. Web applications usually don&#8217;t use RDBMS to manage most of the data served, instead they serve hypertext from a simple file system.</p>
<p>People in the industry are however very reluctant to admit the mismatch of relational databases and network applications.</p>
<p>For instance, RDF stores are actually designed very much like RDBMS, some even are developped &#8220;on top&#8221; of relational databases. And the latest query language supposed to &#8220;light the fire of RDF&#8221;, SPARQL, is nothing more a pathetic attempt to provide SQL developers with a familiar face.</p>
<p>To manage that &#8220;shared and mobile data&#8221; for network applications, I have designed something completely different:</p>
<p>http://laurentszyster.be/blog/pns/</p>
<p>It is a work in progress, but you can allready check it out:</p>
<p>svn://svn.berlios.de/allegra/trunk</p>
<p>http://svn.berlios.de/wsvn/allegra</p>
]]></content:encoded>
				</item>
</channel>
</rss>

<!-- Dynamic Page Served (once) in 0.270 seconds -->
<!-- Cached page served by WP-Cache -->
