IdeaJam(tm) feed for Bill Buchan

Domino Designer / : Rich Mail Support: Replica ID's in the 'Use' Statement

Sun, 09 Mar 2008 13:25:18 +0000

Author: Bill Buchan
Tags: LotusScript Scrip Libraries Rich Mail
Idea: Lets get back to Notes' Rich Mail Support. You remember when Forms were pretty much self-contained, and applications could mail the entire form to a user, for the user to manipulate a form, and for the result to be posted back to the database.

As applications get more complex, we're encouraged to put complex LotusScript code into Script Libraries, which is a Good Thing. However, it means that we cannot eMail that form to an Inbox and expect it to work, unless we take the rather serious step of inserting that script library into all mail files.

So why not allow a Use statement such as:

use "<replicaID>myLibrary"
or use "<filepath>myLibrary"

Where the client will attempt to open the nearest database using that replica ID, and then load the script library. Ideally, latently - that is, after the form is loaded.

In terms of templates, we'd need to see something a little more robust than just the replica ID of course. Perhaps if it supported filepath as well, then we might end up with reusable script library 'libraries' that may pool design elements.. ?

---* Bill

re: Rich Mail Support: Replica ID's in the 'Use' Statement

Wed, 26 Mar 2008 20:43:38 +0000

Author: Michael Kinder
Comment: I love this idea, and feel it is a long time coming. You could create 1 or more databases in your environment that sort of act like LScript DLLs.

Domino Designer / : Agent Manager - schedule ahead...

Mon, 04 Feb 2008 11:18:04 +0000

Author: Bill Buchan
Tags: Agent Manager Agents LotusScript Java
Idea: I've seen a LOT of workflow processing agents in Notes. And the one thing they all have in common is that they have to waken up at a regular interval, check all pending documents, and move around document status.

What any workflow system needs is the ability to schedule an event in the future, such as 'Run this agent against this document in 4 (working) hours'....

Enhancements might include 'If this field is still value xxxx, then run agent yyyy against this document at zz:zz...'

---* Bill

re: Agent Manager - schedule ahead...

Mon, 04 Feb 2008 16:48:31 +0000

Author: Randy Davison
Comment: LEI, LEI, LEI...

It's great for that.

re: Agent Manager - schedule ahead...

Mon, 04 Feb 2008 23:22:52 +0000

Author: Slawek Rogulski
Comment: If you could programmatically schedule { Link } an agent then you could have it run on day x y days in the future. I still support your idea though.

re: Agent Manager - schedule ahead...

Wed, 06 Feb 2008 22:49:00 +0000

Author: Thomas Bahn
Comment: I think, it could be a central Timer Service (new Domino server task), at which you could register agents to run on a specific date/time in the future. This schedule has to be written to disk internally (for power shortages), then there should be options, if/when to run agents, when the server was down, ...

re: Agent Manager - schedule ahead...

Thu, 14 Feb 2008 09:27:07 +0000

Author: Starrow Pan
Comment: Let the server to monitor the value change of a single document in the database is extremely inefficient, at least in current architecture.

re: Rich Mail Support: Replica ID's in the 'Use' Statement

Sun, 09 Mar 2008 17:31:09 +0000

Author: Dan Sickles
Comment: Great idea. Perhaps a URI format that could specify replica IDs and/or Notespaths/filepaths.

re: Rich Mail Support: Replica ID's in the 'Use' Statement

Mon, 10 Mar 2008 12:24:28 +0000

Author: Andreas Imnitzer
Comment: Well, with some dialog window popping up, like: cannot find location of the scriptlib. Where exactly is it? The issue to think about in this, might be: How to make an app aware of needed script libs when being replicated to a local dbdir. Resolve the "use statements" to a temporary copy into db while replicating and checking for update every time? This could lead to a new feature wanted: update mechanism for parts and automated update at replication time.

re: Agent Manager - schedule ahead...

Tue, 11 Mar 2008 00:18:32 +0000

Author: Richard Schwartz
Comment: This is relatively easy to implement on your own through one (or more) queue database(s) where each doc identifies the job to run, the doc to run it on, the time, etc. The advantage of this approach is in the "etc." You get to decide what else needs to go in these job trigger docs. Somehow I doubt that any feature built into the amgr itself would ever get to the level of flexibility that we creative developer types will always end up needing. I designed a highly successful system around this concept, with a Trigger class that was invoked at startup of each agent to read the necessary information from the trigger doc, and then again at termination to update the trigger with info for whatever the next job in the workflow sequence will be. The disadvantage of this approach, of course, is that it probably can't be as efficient -- a master agent has to run through the docs in the queue every few minutes to launch whatever jobs are needed.

re: Rich Mail Support: Replica ID's in the 'Use' Statement

Tue, 11 Mar 2008 14:15:04 +0000

Author: John Vaughan
Comment: This would be great for another reason too - you email something out to a whole lot of people and then discover some weird bug in the code. Too late! But if the script lib pointed to a central place... then you could still fix it. I can think of several instances when this would have been great to have.

re: Rich Mail Support: Replica ID's in the 'Use' Statement

Thu, 13 Mar 2008 15:28:03 +0000

Author: Jan Schulz
Comment: I think it's even better: just add your common stuff in one DB and use it from there: updates without design updates to all apps... just on place to sign, ...

re: Agent Manager - schedule ahead...

Wed, 12 Mar 2008 12:26:18 +0000

Author: Bill Buchan
Comment: Richard - what you've just described is a slightly smarter queue-based trigger mechanism - which still needs to start up and establish workloads every five minutes or so.

What I'm proposing is a flexible way of telling Amgr that this agent would like to be woken up (reliably) at some point in the future (where presumably it could *still* run the same workload management if required).

Thus reducing the amount of load that Amgr has - imagine on a large server, how many templates have 5-minute agents, each wakening up, establishing workload, etc.. I've seen 'thousands' of database instances all trying to do this.

---* Bill

---* Bill