On 10/12/2010 11:06 AM, Adrian Crum wrote:
On 10/12/2010 8:55 AM, Adam Heath wrote:
On 10/12/2010 10:25 AM, Adrian Crum wrote:
Actually, a discussion of database versus filesystem storage of content
would be worthwhile. So far there has been some hyperbole, but few
facts.
How do you edit database content? What is the procedure? Can a simple
editor be used? By simple, I mean low-level, like vi.
How do you find all items in your content store that contain a certain
text word? Can grep and find be used?
How do you handle moving changes between a production server, that is
being directly managed by the client, and multiple developer
workstations, which then all have to go first to a staging server? Each
system in this case has its own set of code changes, and config+data
changes, that then have to be selectively picked for staging, before
finally being merged with production.
What about revision control? Can you go back in time to see what the
code+data looked like? Are there separate revision systems, one for the
database, and another for the content? And what about the code?
For users/systems that aren't capable of using revision control, is
there a way for them to mount/browse the content store? Think nfs/samba
here.
Storing everything directly into the filesystem lets you reuse existing
tools, that have been perfected over countless generations of man-years.
I believe Jackrabbit has WebDAV and VFS front ends that will accommodate
file system tools. Watch the movie:
http://www.day.com/day/en/products/crx.html
Front end it wrong. It still being the store itself is in some other
system(database). The raw store needs to be managed by the
filesystem, so standard tools can move it between locations, or do
backups, etc. Putting yet another layer just to emulate file access
is the wrong way.
<brainstorming>
Let's make a content management system. Yeah! Let's do it! So, we
need to be able to search for content, and mantain links between
relationships. Let's write brand new code to do that, and put it in
the database.
Ok, next, we need to pull the information out of the database, and
serve it thru an http server. Oh, damn, it's not running fast. Let's
have a cache that resides someplace faster than the database. Oh, I
know, memory! Shit, it's using too much memory. Let's put the cache
in the filesystem. Updates now remove the cache, and have it get
rebuilt. That means read-only access is faster, but updates then have
to rebuild tons of stuff.
Hmm. We have a designer request to be able to use photoshop to edit
images. The server in question is a preview server, is hosted, and
not on his immediate network. Let's create a new webdav access
method, to make the content look like a filesystem.
Our system is getting heavily loaded. Let's have a separate database
server, with multiple web frontends. Cool, that works.
The system is still heavily loaded, we need a super-huge database server.
Crap, still falling over. Time to have multiple read-only databases.
</brainstorming>
or...
<brainstorming>
Let's store all our content into the filesystem. That way, things
like ExpanDrive(remote ssh fs access for windows) will work for remote
hosted machines. Caching isn't a problem anymore, as the raw store is
in files. Servers have been doing file sharing for decades, it's a
well known problem. Let's have someone else maintain the file sharing
code, we'll just use it to support multiple frontends. And, ooh, our
designers will be able to use the tools they are familiar with to
manipulate things. And, we won't have the extra code running to
maintain all the stuff in the multiple databases. Cool, we can even
use git, with rebase and merge, to do all sorts of fancy branching and
push/pulling between multiple development scenarios.
</brainstorming>
If the raw store was in the filesystem in the first place, then all
this additional layering wouldn't be needed, to make the final output
end up looking like a filesystem, which is what was being replaced all
along.
-Adrian
-Adrian
On 10/12/2010 7:32 AM, Marc Morin wrote:
With all the other technologies in ofbiz, seems like webslinger just
adds more stuff onto the pile. I don't want to argue the technical
merits of database or file system persistence for a CMS, but it
appears like ofbiz would benefit from reducing the number of
technologies used, and increase the amount of re-use of technologies
it already has.
So, for me, that means entity/service/screen/presentment models are
the core technologies. Galvanizing initiatives around those appear to
provide leverage.
Now don't get me wrong, the "CMS" that is native in ofbiz is
incomplete and needs a lot of work... and for our use case of
providing self edited web sites and ecommerce sites, that appears a
better starting point. We have done things to add self editing etc...
but we need to put a lot more effort into that to ensure that there is
a real solution.
my $0.02.
Marc Morin
Emforium Group Inc.
ALL-IN Software
519-772-6824 ext 201
[email protected]
----- Original Message -----
On 10/11/2010 10:07 PM, Nico Toerl wrote:
On 10/12/10 01:41, Adam Heath wrote:
<snip>
Now, here it comes. The url to the site.
http://ofbizdemo.brainfood.com/.
Things to note. There are *no* database calls *at all*. It's all
done with files on disk. History browsing is backed by git, using
jgit to read it directly in java. CSS styling is rather poor. Most
unimplemented pages should do something nice(instead of a big read
'Not Yet Implemented'); at least there shouldn't be an exceptions
on those pages.
that sounded real interesting and i thought i have to have a look at
this, unfortunately all i got is:
HTTP Status 500 -
------------------------------------------------------------------------
*type* Exception report
*message*
*description* _The server encountered an internal error () that
prevented it from fulfilling this request._
*exception*
java.lang.NullPointerException
WEB_45$INF.Events.System.Request.DetectUserAgent_46$jn.run(DetectUserAgent.jn:166)
Hmm, nice, thanks.
Your user-agent is:
"Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-GB; rv:1.9.2.9)
Gecko/20100824 Firefox/3.6.9"
The (x86_64) is what is causing the problem, I hadn't seen this type
of string in the wild. The regex doesn't like nested (). It's fixed
now.
