D.1 option is more what I was thinking but either way I think keeping the
backend away from the rxml coders and administration access from tags would
allow the backend to change without effecting the rxml using them.
How a user implements administration is then upto the user how they use the
tags. Maybe the ability to add them in the interface as well.
Currently the module I have has configuaration options that supply some site
specific variables to the rxml being parsed so would probably want some
method of specifying variables to be made available to the rxml being parsed
that is more generic and not hardcoded into the module.
This system allow me to setup a some cron scripts (rxml) that our clients
can schedule via an interface of our choice..
Have most of it is working using an external database and table structure
which I have built an administration interface in rxml
I think that I makes sense to work they same way for run times as the linux
cron and not bother with any advanced run checks etc. just parse the files
at the specified time and report any parse errors otherwise leave any other
error reporting upto the rxml to determine what to do.
As I see it if there was a tag to update or add a new entry. That would
trigger that module to reload its entries as well as at boot time.
I suspect using the roxen database would be a good way to store & retrieve
the information but maybe storing also it in a static configuration would
allow for site migrations better.
Cheers for the feed back.
Dave.
On 11/03/09 11:42 PM, "Stephen R. van den Berg" <<srb[at]cuci.nl>> wrote:
> David Hunter wrote:
>> Contemplating creating a roxen module that will handle parsing specified
>> rxml files on a site at a scheduled time similar to the linux cron system
>
>> Currently have a module that is very specific to internal requirements and
>> would like something more open and useable by anyone.
>> So far looking at providing an emit plug-in to display the current entries
>> and tags to add new and update existing entries.
>
> The following comes to mind:
> a. This could be implemented external to Roxen, but I understand the desire
> to make it configurable through a module.
> b. If you want to make it configurable through tags, where are you going to
> store the configuration information?
> c. Anyone doing complex tasks will back it up with a configuration in SQL.
> d. Which leaves two possible angles (in my view):
> 1. Keep it as simple as possible and just support calling files at
> regular intervals (possibly with the flexibility and configuration
> of regular crontab(5) options) defined by a static configuration
> only accessible through the standard Roxen configuration interface.
> 2. Create a full integration with SQL which defines which runs when.
> The only glue you offer is that the module can be signaled
> that it should reload the configuration from SQL to check for changes
> done through direct SQL commands.
> e. In either case, providing update and enumeration functionality in the
> module
> proper is overkill (in simple case 1 there is no need to update or
> enumerate, in case 2 all that can be done using regular SQL).
|