binarycloud-dev

[binarycloud-dev] Practical use of r2

[Phillip S. <te...@al...>]

Greetings.

I've been lurking on this list for awhile now, and have an interest
in BC's capabilities.  I consider myself to be an intermediate PHP
developer, and am contemplating the possibility of using r2 as the
framework for a project.

Specifically, there is an existing open source project [ Ministry of
Truth - http://mot.sourceforge.net ] that is no longer being actively
maintained.  I am giving serious thought to picking up development
because I've not found any other software that fills the same niche,
and because I've spoken with the original author who has encouraged me to
do so. The problem with this is that I am not comfortable with the way its
idea/essence is currently implemented, and would really want to rebuild it
from the ground up (the TODO and feature list is long, and it seems pointless
to try re-inventing the wheel with what's there).  For those that don't
care to visit the website, MOT currently allows one to group db tables/fields
relationally into larger more useful things (e.g project tracking,
hardware/software inventory, etc.), all without having to know anything about
html/php/sql (given that it was originally written in 1998 and includes its
own built-in XML parser, it's still an impressive and usable piece of
software).

r2 would appear to be a candidate for a new MOT framework (other
possibilites might be Horde [ http://www.horde.org/ ]), but I have concerns
about how to create a distributable "product" based on it (MOT will continue
to be strictly GPL, of course).  I'm having difficulty envisoning how I
would incorporate it in such a way as to minimize the setup requirements for
my user base.  For some, getting Apache and PHP installed is enough of a
hurdle (not everyone uses .rpm or .deb based systems).  Would I say "you
need Apache, PHP (plus all it's special dependencies), and r2 .. after you
fight with that, you use MOT as a plug-in", or is there a recommended way I
could easily encapsulate r2's overhead into my configuration system?  I would
like to be able to say "Here's MOT.  Run the installer." once they have
met the Apache/PHP requirement.

Second, how viable is r2 as a development platform right now?  Obviously
it's still under heavy development, but is it becoming mature enough to
start building production-quality applications?  I expect that it will take
me a few weeks to spec out what I will include as part of the initial rewrite
of MOT (its existing functionality plus a subset of the TODO), so my question
is more focused on the "stable" parts of r2.  In other words, which
components of MOT can I concentrate on re-implementing now using the least
changing parts of r2?  The website/documentation doesn't give a clear
indication of what's complete and what's not.. guess I can always dive
in and find out though.

Looking at the mailing list archives, I see that some of my questions
are answered (lots of recommendations from Alex to use r2 over r1 at this
point).  The recent "BC quick-start guide" thread is helpful, but I don't
see anyone trying to use BC for something like this (most uses seem to be
for custom website projects rather than a self-contained, portable web
application).  Correct me if I'm wrong.

Just to be clear, I'm not in a major hurry here.  If I was, then I would go
ahead and consider r1 and worry about the conversion issues later.  I get
the feeling though that I will be able to plan my goals around r2's
development cycle, and that enough of r2 is complete now.  It would be
helpful to have some idea on the overall status and usability of specific r2
sections (documentation on all this once r2 is finished is great, but I
would still like to start developing now), and I would appreciate general
feedback from anyone who is currently using it to do productive things.

Thanks in advance (I tried getting subscribed to bc-general to post
this there instead, but sourceforge seems to be eating my confirmations
at the moment).  Also, the BC website still states that bc-dev is for dev
and support.  Apologies if this isn't the best place for my inquiry.

-phillip

-----------------------------------------------------------------
 UNIX Systems Administrator	*windowmaker.org site maintainer
-----------------------------------------------------------------

Re: [binarycloud-dev] Practical use of r2

[alex b. <en...@tu...>]

> Specifically, there is an existing open source project [ Ministry of
> Truth - http://mot.sourceforge.net ] that is no longer being actively
> maintained.  I am giving serious thought to picking up development
> because I've not found any other software that fills the same niche,
> and because I've spoken with the original author who has encouraged me to
> do so. The problem with this is that I am not comfortable with the way its
> idea/essence is currently implemented, and would really want to rebuild it
> from the ground up (the TODO and feature list is long, and it seems
pointless
> to try re-inventing the wheel with what's there).  For those that don't
> care to visit the website, MOT currently allows one to group db
tables/fields
> relationally into larger more useful things (e.g project tracking,
> hardware/software inventory, etc.), all without having to know anything
about
> html/php/sql (given that it was originally written in 1998 and includes
its
> own built-in XML parser, it's still an impressive and usable piece of
> software).

Sounds cool.
Also sounds like it has great potential for integration with metabase,
because of metabase's xml schema definition format.

> r2 would appear to be a candidate for a new MOT framework (other
> possibilites might be Horde [ http://www.horde.org/ ]), but I have
concerns
> about how to create a distributable "product" based on it (MOT will
continue
> to be strictly GPL, of course).  I'm having difficulty envisoning how I
> would incorporate it in such a way as to minimize the setup requirements
for
> my user base.  For some, getting Apache and PHP installed is enough of a
> hurdle (not everyone uses .rpm or .deb based systems).  Would I say "you
> need Apache, PHP (plus all it's special dependencies), and r2 .. after you
> fight with that, you use MOT as a plug-in", or is there a recommended way
I
> could easily encapsulate r2's overhead into my configuration system?  I
would
> like to be able to say "Here's MOT.  Run the installer." once they have
> met the Apache/PHP requirement.

Oh, yeah, you could do that. It would require you to set up a stable config
you like of r2, do a build from the source tree, and distribute the build
tree with your installer.

It's entirely doable, keep in mind that the current r2 codebase is in
development, so it's not exactly focused on simple installation :)

> Second, how viable is r2 as a development platform right now?  Obviously
> it's still under heavy development, but is it becoming mature enough to
> start building production-quality applications?  I expect that it will
take

It's ready, now.
However: you will not have access to some of the more advanced tools that
will be available for the system in the next month or so. (EntityManager,
QueryManager, TableBuilder, FormBuilder)

> me a few weeks to spec out what I will include as part of the initial
rewrite
> of MOT (its existing functionality plus a subset of the TODO), so my
question
> is more focused on the "stable" parts of r2.  In other words, which
> components of MOT can I concentrate on re-implementing now using the least
> changing parts of r2?  The website/documentation doesn't give a clear
> indication of what's complete and what's not.. guess I can always dive
> in and find out though.

The module spec and page render pipeline are both mature. What remains is
extensions to the make system, and integrating managers + builders.

> Looking at the mailing list archives, I see that some of my questions
> are answered (lots of recommendations from Alex to use r2 over r1 at this
> point).  The recent "BC quick-start guide" thread is helpful, but I don't
> see anyone trying to use BC for something like this (most uses seem to be
> for custom website projects rather than a self-contained, portable web
> application).  Correct me if I'm wrong.

You are correct, but the system is designed to support any php app, so you
won't have a problem.

> Just to be clear, I'm not in a major hurry here.  If I was, then I would
go
> ahead and consider r1 and worry about the conversion issues later.  I get
> the feeling though that I will be able to plan my goals around r2's
> development cycle, and that enough of r2 is complete now.  It would be

Yes, you are correct.
R2, even at this stage, is more mature than r1. r1, while is is a functional
system, is almost an experiement: most of the code is procedural, the tools
aren't mature, etc.

R2 is much more heavily "designed" and while some of the code is still a
moving target, the system is stable and partially functional. You can build
modules for it, now.

> helpful to have some idea on the overall status and usability of specific
r2
> sections (documentation on all this once r2 is finished is great, but I
> would still like to start developing now), and I would appreciate general
> feedback from anyone who is currently using it to do productive things.
>
> Thanks in advance (I tried getting subscribed to bc-general to post
> this there instead, but sourceforge seems to be eating my confirmations
> at the moment).  Also, the BC website still states that bc-dev is for dev
> and support.  Apologies if this isn't the best place for my inquiry.

Heh, I shoud change that :)

These sorts of discussions are relevant here, btw.

:)

_a

Re: [binarycloud-dev] Practical use of r2

[John D. <jo...@we...>]

On Wed, 15 Aug 2001, Phillip Smith wrote:

> 
> 
> Specifically, there is an existing open source project [ Ministry of
> Truth - http://mot.sourceforge.net ] that is no longer being actively
> maintained.  I am giving serious thought to picking up development
> because I've not found any other software that fills the same niche,
> and because I've spoken with the original author who has encouraged me to
> do so. The problem with this is that I am not comfortable with the way its
> idea/essence is currently implemented, and would really want to rebuild it
> from the ground up (the TODO and feature list is long, and it seems pointless
> to try re-inventing the wheel with what's there).  For those that don't
> care to visit the website, MOT currently allows one to group db tables/fields
> relationally into larger more useful things (e.g project tracking,
> hardware/software inventory, etc.), all without having to know anything about
> html/php/sql (given that it was originally written in 1998 and includes its
> own built-in XML parser, it's still an impressive and usable piece of
> software).
> 

There is actually some overlap as far as which capabilities each project
provides. I think we've implemented a lot of MoT's lower-level functionality,
but there are definetly key pieces missing, notably user (read: web based)
creation and management of tables (which means user creation of entities). At
this point all entities are created by the developer at development time.
That's a pretty big jump.  

I could almost see MoT as filling two roles: both the role in which it is
currently used, and for actually simplifying development of binarycloud
applications, by allowing developers to create tables and entities through a
nice interface. 


Here is the MoT features list, with my comments after each:

The ability to create and modify databases, tables, fields, and permissions,
all from a point and click, web interface. 

(jd: I've never thought of having an entity represent a tablespace as opposed
to a table. I'm going to have to think about this, but it would probably make
an interesting extension)

Support for links between tables. Jobs may be linked to users, equipment, and
software. People may be linked to department, companies, contacts, and
machines. 

(jd: entities are structured objects. One entity can nest another, partially or
fully, so this is part of what r2 will provide with the entitymanager. Giving
users the ability to define their own entities would be another interface that
doesn't exist now, however)

Support for multiple users and read, add, and modify permissions for each user
for each table. 

(jd: the permissions system conceptualized for bc is amazing, incorporating
very complex session management and a notion of roles (user-created definitions
of permissions). it's also vaporware at the moment)

Support for sorting and restricting every table to a fully configurable set of
fields (sort a list of jobs by priority, close date, or tech, or restrict the
same list of jobs to a specified contact). 

(jd: this is completely provided for by our lister class, another forthcoming
part of r2. It also does filtering on a per-field level)

Support for actions, which are custom scripts automatically fired by specified
database actions (adds, modifications, etc.). This is immensely helpful for
implementing things like email notification and timestamping. 

(jd: we have the notion of events in the entitymanager, which are
add()/delete()/set()/get() etc.. A developer can associate functions to be
called with a specific entity's events. The way we do this now is by
subclassing and extending the base entitymanager for that specific entity. This
might be too heavy-handed so another approach may be necessary, hrmm..)

Basic support for writing custom sql queries. This will eventually include a
custom query page but is very helpful now in the creation of actions. A sample
mot_sql query that joins three tables together and grabs a value from the third
table looks like: select {People}.[email] from {Jobs} <Users> <Personal
Information> where {Jobs}.[id] = $row_id 

(jd: we have a standard set of queries associated with every entity that are
generated as part of a developer's 'make' process. There isn't a clean way to
do custom entity-related queries right now, but this only requires minor
re-engineering. Instead of having people write custom queries, it would be much
cooler to have them write XML-based views, at least for selects)

Support for importing and exporting database schemas. 
(jd: no idea. I hate databases anyway. Especially Oracle.)

Support for database-specific help files. All you have to do is write the text. 
(jd: see above)

(jd: just kidding. We currently can export any entity to XML, and from there an
XSL transform takes it to CSV or PDF. Pretty fucking slick. You can export
either lists or single objects.)

Basic searching capabilities. 
(jd: not something we've ever needed in our application, so I haven't really
thought about this. you can effectively 'search' a lister with filters, but not
more than one entity at a time..)

CSS support for configuring the interface. 
(jd: no idea)


I think there is a good synergy between these two pieces of software. I
definetly think you'd get more (as long as you're willing to wait :)) out of
binarycloud than you would out of something like Horde.. 

-- 

John Donagher
Application Engineer, Intacct Corp.

Public key available off http://www.keyserver.net
Key fingerprint = 4024 DF50 56EE 19A3 258A  D628 22DE AD56 EEBE 8DDD