[Prev][Next][Index][Thread]

Re: databases: storing pages in / web front ends to (response)




Hi, 

Another Software Engineer on our project pointed out your request, I will 
answer with a standard response about our tool and invite all to visit, 

http://rbse.mountain.net/MOREplus/ , for additional information/evaluation.

MOREplus is a World Wide Web-based cataloging and database tool. MOREplus
allows you to develop, deploy and maintain complex information retrieval 
systems without writing Common Gateway Interface-based (CGI) scripts or 
developing databases. MOREplus can manage a broad range of file types 
that are located anywhere on the Web.

Unlike many Web search engines, and database forms generation tools, 
MOREplus is built for information assets (holdings) that have high value to 
Administrators -- Administrators who don't have much time to muddle 
through long lists of assets. This need arises as organizations seek to 
promote and distribute proprietary and mission critical information 
across traditional boundaries. Corporate best practice descriptions,
metrics data, or software can all be examples of high-value information 
assets.

MOREplus provides a lot more than an Internet search engine. It enables 
you to meet a broad set of constraints and demands that are imposed on 
suppliers of such high-value assets -- without hiring a cadre of Web gurus.

Well, hope it helps, and please do come and visit, Bob Terry.


The original Post from Robin Stephenson was:

> 
>   I'm currently running a Web site based on a BSD/OS v2.0.1 platform,
> possibly to be changed to Solaris.  The server software is Netscape's
> Commerce Server, which seems to be fine.
>   I'd like to be able to support access in multiple languages, keep
> track of user preferences (using a login dialog to identify users),
> etc.  At the moment this is implemented with some home-brewed Perl
> scripts, which are decidedly flaky.
>   My short-term aim (read: next month or so) is to identify some way
> of putting Web pages into a database as objects, and having an object
> server sitting inbetween our httpd and the database files.  Ideally
> I'd have some way of ensuring (or at least checking) link integrity,
> etc.  The appeal of this solution to me is that it is scaleable, and
> in the long term I may have to manage thousands of Web pages, rather
> than the few dozen I do at the moment.
>   Another thing that I'd like to be able to do is implement a Web
> front-end to a transaction-processing database - e.g. write a simple
> script to get information from a form, tell the database it's a
> payment, or a debit, and have the database do most of the work (then I
> can get on with writing nice Web pages, and leave Perl more-or-less
> alone...)  It seems to make sense to me to implement both database
> systems on a common platform, or at least with a common interface.
> 
>   So, now to the questions:
> 
> 0) Meta-question.  Am I asking the right questions?
> 
> 1) Has someone done this already?  I don't want to be reinventing the
>    wheel.  If there's a reasonably cost-effective solution out there,
>    I'll use that.
> 
> 2) Which database would you recommend?  I've come across a database
>    from a company called JustLogic - does anyone have experience of
>    using this for this sort of application?  I'm loth to spend a
>    fortune on something as high-powered as Oracle if we can (for trial
>    purposes) get away with something cheaper.  Anything we use needs
>    to be `upward-compatible' though - does this limit me to SQL?
>    Should I demand SQL anyway?
> 
> 3) Is there a commercial all-in-one package that would do this -
>    provide a database-like way of maintaining Web trees?  I've looked,
>    and the only thing I could find was Adobe's SiteMill, which is
>    Solaris only.  We won't be buying the Sun unless the BSD trial
>    works out...
> 
> Thank you for any help - I'm very new to this, and would appreciate
> any advice you can offer.
> 
> --
> Robin Stephenson.      (send email with subject `send pgp key' for pgp key)
> 
> 
> 
> -- 
> Ravi S. Vedula
>