So I don't get modded down to hell, this is an on-topic connection to Zope, hierarchical DBs, XML, and data storage.
supton> For Java folks, I think the usefulness of Zope (well, just
supton> ZODB) will come as 3rd party CORBA support matures; using ZODB
supton> as a data-store for Java apps could be very interesting.
Possibly. SOAP (or XML-RPC) may be an easier route than CORBA though.
It wasn't really an option when I last looked at Zope, but SOAP (and
Zope) have matured since. CORBA is kind of a dirty word.
I was thinking about this today - using SOAP as a transport between
Zope and Java. I'm sure my thoughts here aren't new at all, but I
work on a large system so I can relate the ideas to at least one
complex real system.
The question to me doesn't seem to be whether we should bring back
hierarchical databases, but whether any storage format or API is a
good choice for manipulating data, period. I will come back to this.
Currently we store documents for a large document delivery system in
our own internal binary format which is partially parsed and indexed
so that we can retrieve, manipulate, and display documents and parts
of documents more quickly. The XML is sent to servlets on a web front
end for the most part, across COM in some instances, and even to a
mainframe.
As time goes on, our ability to make this process more dynamic
increases due to increased processing power. New features will drive
the need for more dynamic data, more ways to make the data useful
information.
So, Zope says it integrates with RDBMSs and I'm sure it can, using
ODBC. Zope could access some of our data directly, and some data over
SOAP. (Believe me we aren't going to stop using DB2. We need
industrial strength data storage for many terabytes of data with
backup, failover, replication and all that fun stuff, and DB2 is the
primary corporate database system for us).
Now, RDBMSes can handle hierarchical data (n-ary trees) fine in the
sense that they can store them efficiently enough. However, SQL is
not a convenient way to get at it because you have to chase pointers
around essentially and the queries get to be complicated. What we do
is layer Java classes on top of data access, including these complex
structures. Everyone and their mom does this.
Most SQL is buried in the system and we "see"
object representations in servers and applications. This is all fine
and good for now; it's just not that general or dynamic. Access for
each type of data in the RDBMS is usually through one set of classes and
is almost always specific to the service that is the primary user.
For example, you can get results from a search engine, but you can't
directly access the search engine's index data. You just get results
from your query. This is okay for encapsulating data access, but bad
for reusing the same original data for other purposes.
In other words, I don't think it's so much RDBMSes or databases in
general that are the problem. They can be used to -store- complex
data. SQL may just not provide a great API to -use- the data. A lot
of XML isn't semantically hierarchical anyway, any more than an ASCII
document is necessarily referring to one long string.
So a hierarchical storage system wouldn't necessarily be better since
it wouldn't really work to represent non-tree data . It may be wonderful for hierarchical-only data, but we have a lot of
different kinds of data.
I think the real issue is mapping between many different data storage
formats so that you can use many different APIs and different
components on the same data, not looking for the holy grail storage
system or query language.
We already convert objects sent between services to XML dynamically
because most traffic goes through message queues, so at runtime we can
really represent the data any way we want. Java JDK 1.4 will even
serialize directly to XML.
So how could you use Zope, an ODBMS, or some other future system as an
alternative API to the data in the RDBMS? ZODB could just be used to
cache the data Zope gets from Java or the database. That way, you
don't have to replace DB2 or create a whole new set of databases that
have copies of the data. You can provide alternative XML/OO-friendly
access to the same data by routing through Zope, and keep it efficient
by caching.
I doubt anyone made it this far:), but, in summary, one way to tackle
"hierarchical" XML data or other structured data is to use a non-RDBMS
system at runtime only. The company I work for does this to an
extent with Java objects, but you could make it more general. The pieces are:
1) components that extract data from each source (LDAP, RDBMS, files,
etc.) and present it as XML. Ideally you could make a generic system
for all data types in each source. In the worst case you'd provide
one XML translator for each group of data.
2) proxies that convert this XML into some runtime native object
representation for each language (Java, Python, C, etc.).
3) possibly a metadata format such as RDF to describe the structure of the data.
Now every component can access any data as XML without caring what the
original format was. You have to know what the data means to use it, but not
how to decode it. Then you can provide many types of APIs or
services, in different languages if desired, that manipulate the same
data more conveniently than the native API of the data source like SQL
or LDAP.
Oh, yeah I forgot - the Navy site was also down
when I posted my original followup.
I have actually played with zope before.
It isn't really useful to me since
nearly everything at work is Java-based,
though certainly it has many good ideas.
The tour's "what can I do with zope?" page has 4
demo sites.
appwatch.com - closed down
stormlinux.com - asks for a zope login which I
don't have
zope.org - amazingly, this one works
technocrat.net - errors with connection refused
connecting to technocrat.net:9673
So, apparently Zope is good for running zope.org
and nothing else...
I meant clearly independent to the user. Most
if not all Unix users have operated Unix through a
terminal session, for example. You can do that to an extent
with Windows now. And stable/usable certainly
does not mean Linux GUIs leave nothing to be desired.
However, I can see by your ad hominem attacks that
you want a flame war and not an intelligent discussion, so whatever. Cheers.
I don't see the appeal either. Talk about
mediocre and unfunny. I wish they would have clearly
marked this article as being about User Friendly so I could have
skipped it. No, I didn't read the review.
Well, the Pentium IV is slower than an
equally clocked Pentium III, right? Maybe this is
a new trend in computing. Look forward to
new slower and smaller capacity hard drives from
IBM, at an increased price, in the near future!
Yes, the GUIs on Linux leave something to be
desired, but they are clearly independent of the
kernel and low-level graphics system. Changing
them is a part of the system rather than
something requiring hacks or procedures not documented for users. I have found KDE to
be perfectly usable and extremely stable, plus
there's a real OS underneath it.
I realize you're just a juvenile delinquent troll, but
the X-Box has a 733 MHz Pentium III CPU and the
GameCube has a 485 MHz PowerPC-derived CPU
according to Gamespot. Also, the
GameCube uses 1T-SRAM for main memory in addition
to DRAM which is interesting.
It does work well to an extent. Rare lyrics are
hard to find with Google.
The main problem is that
Google does not have true phrase searching.
You can demonstrate this by searching for something
in quotation marks, then looking at the
highlighted search terms on a cached page. (It's
also mentioned on Google somewhere).
But it isn't free - I have to deal with those annoying ads. Advertisers pay you to put up ads for people like me to see. And believe me that
I care more about my convenience than your income.
If the ads are a nuisance (like popups) I browse elsewhere. What makes you think your content is so great that
I should be willing to suffer to line your pockets with ad revenues?
There are many websites. There is really no
content that is that unique or highly valuable to me that I can't live without it.
_True_ audiophiles like myself only listen
to virgin LPs in their cars. When I'm done,
I just roll the window down and toss it. I
use a Graham 2.0 tonearm and Benz cartridges
on a specially tweaked Rega with a $50000 Krell
monoblock amp. I am saving up to get another
amp for stereo (hopefully soon as Neil Diamond sounds much better with the extra channel).
-Kevin
The Canadian market for satellite radio has been
exceptionally strong for the past year. With
little public advertising, it is clear that
word of mouth about the units has been enough
to keep the market extremely active.
According to J. R. Sputnick, Chief
Technical Officer at XMRadio, "So far,
customers have been very happy with our service
at the current rate of 20 CDN per month. We may
never even broadcast there. Damn those
Canadians are dumb."
Slashdot Mirror
I find it interesting that you say Java isn't suited for large scale server processes since I work on large scale server process in Java :).
-Kevin
supton> For Java folks, I think the usefulness of Zope (well, just
supton> ZODB) will come as 3rd party CORBA support matures; using ZODB
supton> as a data-store for Java apps could be very interesting.
Possibly. SOAP (or XML-RPC) may be an easier route than CORBA though.
It wasn't really an option when I last looked at Zope, but SOAP (and
Zope) have matured since. CORBA is kind of a dirty word.
I was thinking about this today - using SOAP as a transport between
Zope and Java. I'm sure my thoughts here aren't new at all, but I
work on a large system so I can relate the ideas to at least one
complex real system.
The question to me doesn't seem to be whether we should bring back
hierarchical databases, but whether any storage format or API is a
good choice for manipulating data, period. I will come back to this.
Currently we store documents for a large document delivery system in
our own internal binary format which is partially parsed and indexed
so that we can retrieve, manipulate, and display documents and parts
of documents more quickly. The XML is sent to servlets on a web front
end for the most part, across COM in some instances, and even to a
mainframe.
As time goes on, our ability to make this process more dynamic
increases due to increased processing power. New features will drive
the need for more dynamic data, more ways to make the data useful
information.
So, Zope says it integrates with RDBMSs and I'm sure it can, using
ODBC. Zope could access some of our data directly, and some data over
SOAP. (Believe me we aren't going to stop using DB2. We need
industrial strength data storage for many terabytes of data with
backup, failover, replication and all that fun stuff, and DB2 is the
primary corporate database system for us).
Now, RDBMSes can handle hierarchical data (n-ary trees) fine in the
sense that they can store them efficiently enough. However, SQL is
not a convenient way to get at it because you have to chase pointers
around essentially and the queries get to be complicated. What we do
is layer Java classes on top of data access, including these complex
structures. Everyone and their mom does this.
Most SQL is buried in the system and we "see"
object representations in servers and applications. This is all fine
and good for now; it's just not that general or dynamic. Access for
each type of data in the RDBMS is usually through one set of classes and
is almost always specific to the service that is the primary user.
For example, you can get results from a search engine, but you can't
directly access the search engine's index data. You just get results
from your query. This is okay for encapsulating data access, but bad
for reusing the same original data for other purposes.
In other words, I don't think it's so much RDBMSes or databases in
general that are the problem. They can be used to -store- complex
data. SQL may just not provide a great API to -use- the data. A lot
of XML isn't semantically hierarchical anyway, any more than an ASCII
document is necessarily referring to one long string.
So a hierarchical storage system wouldn't necessarily be better since
it wouldn't really work to represent non-tree data . It may be wonderful for hierarchical-only data, but we have a lot of
different kinds of data.
I think the real issue is mapping between many different data storage
formats so that you can use many different APIs and different
components on the same data, not looking for the holy grail storage
system or query language.
We already convert objects sent between services to XML dynamically
because most traffic goes through message queues, so at runtime we can
really represent the data any way we want. Java JDK 1.4 will even
serialize directly to XML.
So how could you use Zope, an ODBMS, or some other future system as an
alternative API to the data in the RDBMS? ZODB could just be used to
cache the data Zope gets from Java or the database. That way, you
don't have to replace DB2 or create a whole new set of databases that
have copies of the data. You can provide alternative XML/OO-friendly
access to the same data by routing through Zope, and keep it efficient
by caching.
I doubt anyone made it this far
"hierarchical" XML data or other structured data is to use a non-RDBMS
system at runtime only. The company I work for does this to an
extent with Java objects, but you could make it more general. The pieces are:
1) components that extract data from each source (LDAP, RDBMS, files,
etc.) and present it as XML. Ideally you could make a generic system
for all data types in each source. In the worst case you'd provide
one XML translator for each group of data.
2) proxies that convert this XML into some runtime native object
representation for each language (Java, Python, C, etc.).
3) possibly a metadata format such as RDF to describe the structure of the data.
Now every component can access any data as XML without caring what the
original format was. You have to know what the data means to use it, but not
how to decode it. Then you can provide many types of APIs or
services, in different languages if desired, that manipulate the same
data more conveniently than the native API of the data source like SQL
or LDAP.
-Kevin
Oh, yeah I forgot - the Navy site was also down
when I posted my original followup.
I have actually played with zope before.
It isn't really useful to me since
nearly everything at work is Java-based,
though certainly it has many good ideas.
-Kevin
I just went to zope.org.
The tour's "what can I do with zope?" page has 4
demo sites.
appwatch.com - closed down
stormlinux.com - asks for a zope login which I
don't have
zope.org - amazingly, this one works
technocrat.net - errors with connection refused
connecting to technocrat.net:9673
So, apparently Zope is good for running zope.org
and nothing else...
-Kevin
Moderators: here's a nickel, buy a clue.
As the anonymous followup says, Solaris is
the distribution, and SunOS is the kernel.
(like RedHat is a distribution and Linux
is a kernel)
-Kevin
Books have *not* been doing this for thousands
of years.
The problem is enforcement of some nonelected
group's opinion on what you should be allowed
to see. Controlling the flow of information
is a big deal.
-Kevin
However, I can see by your ad hominem attacks that you want a flame war and not an intelligent discussion, so whatever. Cheers.
-Kevin
-Kevin
The Pentium IV 2.0 GHz is hardly a "dog". Not
according to streams, specint, and specfp anyway.
-Kevin
-Kevin
My, you paint with broad brushes.
Yes, the GUIs on Linux leave something to be
desired, but they are clearly independent of the
kernel and low-level graphics system. Changing
them is a part of the system rather than
something requiring hacks or procedures not documented for users. I have found KDE to
be perfectly usable and extremely stable, plus
there's a real OS underneath it.
-Kevin
Yes and whomever gave you offtopic is a dumbass.
-Kevin
XP being "controversial" doesn't have anything to do with it.
The techs just need time to train according to the article.
-Kevin
Damn. I have been transported to a gamer web board.
u r 2 cool 4 me, man
-Kevin
-Kevin
Thank God Microsoft is going to put the Internet
to "practical use" so we can stop pissing our
time away out here.
-Kevin
1000 _songs_ is more like 100 CDs, dude. 5GB
ain't what it used to be.
-Kevin
Please mod parent as humor-challenged.
-Kevin
I can't believe how horrible Perl 6 looks.
-Kevin
Answer: particle swarm optimization
2.739 1.988 0.854 1.529
1.581 0.871 2.840 1.818
2.482 0.861 1.414 2.353
2.071 1.729 2.523 0.787
1.302 1.321 3.192 1.295
1.587 2.860 1.786 0.877
2.927 1.106 1.952 1.125
1.827 1.316 0.995 2.972
3.054 1.085 1.238 1.733
2.307 2.089 0.752 1.962
Coding is left as an exercise for the reader.
-Kevin
The main problem is that Google does not have true phrase searching. You can demonstrate this by searching for something in quotation marks, then looking at the highlighted search terms on a cached page. (It's also mentioned on Google somewhere).
-Kevin
If the ads are a nuisance (like popups) I browse elsewhere. What makes you think your content is so great that I should be willing to suffer to line your pockets with ad revenues?
There are many websites. There is really no content that is that unique or highly valuable to me that I can't live without it.
-Kevin
_True_ audiophiles like myself only listen
to virgin LPs in their cars. When I'm done,
I just roll the window down and toss it. I
use a Graham 2.0 tonearm and Benz cartridges
on a specially tweaked Rega with a $50000 Krell
monoblock amp. I am saving up to get another
amp for stereo (hopefully soon as Neil Diamond sounds much better with the extra channel).
-Kevin
Why talk to other people when you can talk
... variety? The opportunity to
to yourself?
I don't know
listen to stuff you otherwise might not be
exposed to? Think for a few seconds, man.
-Kevin
CANADIAN SATELLITE RADIO SECOND ONLY TO HOCKEY
TORONTO (AP)
The Canadian market for satellite radio has been
exceptionally strong for the past year. With
little public advertising, it is clear that
word of mouth about the units has been enough
to keep the market extremely active.
According to J. R. Sputnick, Chief
Technical Officer at XMRadio, "So far,
customers have been very happy with our service
at the current rate of 20 CDN per month. We may
never even broadcast there. Damn those
Canadians are dumb."
-Kevin