I am curious how do you all think LocalFS would perform for such a big
Use Zope for managing meta-data, or mayeb even better Zope + a fast DB tool
for the metadata part.
Let Zope do its holy best for the 'virtual-object interfacing' jobs, let the
others do their thing..
My understanding was that using the LocalFS is as fast as you can get really
and that any file size limits are to do with the OS, disks RAM, caching etc,
not Zope or anything else. Plus one is free to scale or mix and match zope
with other tools and systems, as it develops without compromising all the
work which has gone into the base data's filestructure. Might be much
easier to develop too..
The data would not be locked into Zope or for that matter any RDBMS
'solution'. One coud performance tests, develop optimizations and determin
along the way when and where to apply them.
No headaches as Zope goes through upgrades either because one is not taxing
it too much.
Can anyone see what are the faults with this approach?
I have been wondering about such what plan to use and if or with Zope for
large animated map datasets project. This would use Flash SWF, and also SVG
[XMLbased Scalable Vector Graphics]
The SWF can be merged into Quicktime allowing for multiple tracks.
This is a powerful combinatoin where one needs to package trainging,
presentation. Video though big contains a huge amount of 'information' which
is lost in all other infromation system: body language, human language, tone
of voice, inflexion, accent, emphasis, mood, lighting, context, scale,
enviromnental conditions. etc.
Jason CUNLIFFE = NOMADICS.(Interactive Art and Technology).Design Director
----- Original Message -----
From: Dieter Maurer <[EMAIL PROTECTED]>
To: Jerome Alet <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Tuesday, September 19, 2000 3:44 PM
Subject: Re: [Zope] Should I use ZODB or not ?
> Jerome Alet writes:
> > Our needs are to store hundreds, and possibly thousands of MPEG2 and
> > (generally short) video movies, MP3 audio files, JPEG images, etc...
> > Altough most of the files will be in the 1 Mb -> 10 Mb range, some
> > be larger, e.g. some Gigabytes.
> > For each file we also want to keep some data: author, subject,
> > description, keywords, domain, etc...
> > I see 5 solutions:
> > 1 - store both files and their associated datas in ZODB
> > 2 - store files in the filesystem and datas in ZODB
> > 3 - store files in the filesystem and datas in an RDBMS
> > (use Zope only for the presentation of files and datas)
> > 4 - store files in ZODB and datas in an RDBMS.
> > 5 - don't use Zope at all because it's not appropriate.
> Do not store the files in Zope or serve them with Zope.
> A standard web server (e.g. Apache) is at least one order
> of magnitude faster than Zope for static content (such as
> multi media files). This is essential for you
> large file objects.
> If you have up to a few thousand objects and they do not change too
> often, you can put them (the meta data) into the ZODB.
> Otherwise, put them in a RDBMS.
> I would use the RDBMS whenever I have one or I have more than
> a few hundred objects or I would need access to the data
> from legacy processes, too.
> Zope maillist - [EMAIL PROTECTED]
> ** No cross posts or HTML encoding! **
> (Related lists -
> http://lists.zope.org/mailman/listinfo/zope-dev )
Zope maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists -