[whups] new to whups

[Chuck Hagenbuch]

Quoting Gary Weinreb <gweinreb@rocksolidsystems.com>:

> Beautiful.  This is coming together nicely.
> Reports also.  Are you thinking about some preferences for these?  i.e.
> Bar vs. Pie, color pickers, etc.

Not really so far - the graphing stuff is just getting taking shape, and 
right now the logic for what kind of chart to produce is: pie chart if the 
backend can, otherwise bar - or, if a pie doesn't make sense, bar.

> Chuck, if you saw my post last week about Whups - Turba Integration, this
> idea evolved (devolved?) into Whups pulling from a specific Turba-List
> that might be statically named "project_clients", so that Turba backend
> transparency would be maintained as far as Whups is concerned, etc.  A
> generic Whups <-> Turba-List mechanism could be developed, so that it
> would be easy to set up Lists in Turba, for use in Whups as Clients, and 
> for Notification, such as External, Internal, Internal Admin, etc. either 
> for Contexts of Whups, or per Module/Client, or per Project?  I don't yet
> clearly see at what levels of granularity we can (or want to) break
> Notification down to.  I'd like to continue to see dialog, for example
> with Mike Baptiste (current post...) regarding the permissions / 
> notification mechanism...

The lists stuff sounds good to me. I'm kind of still waiting to see where 
you think the notification stuff should go, too. :)

> I see that you are working on this stuff currently, so I'll just try and
> contain my enthusiasm to constructive feedback...

Don't be too complacent. ;) I'm doing my best, but I have a lot of other 
things to work on and am, at this point, mainly trying to get things in 
good enough shape to have Whups running bugs.horde.org.

> Maybe hash is the wrong term.  What I mean is that we create a method
> within Whups to create/encode and later read/decode nag_task records,
> such
> as:  (very psuedo code here...)
>          nag_tasks.task_owner =
> "WHUPS_RULE:$whups_module:$whups_type:$state"
>          nag_tasks.task_desc being encoded with arrays of
> action:action_subjects:
>           
> a:3{NOTIFY_INTERNAL[bob,mary,tom,gilligan]:CREATE_TASKS[__bob__
[$some_task_ID,$some_task_ID],__skipper__[$some_task_ID]],NOTIFY_EXTERNAL
[turba.project_ABC123_external]}
> using the methods for encoding/decoding arrays in to/out of, text fields,
> which are already in use throughout Horde (and which I'm assuming are
> available via API)...
> 
> They are, aren't they?

I think you mean serialize/unserialize - http://www.php.net/serialize
I'm still not conviced that it's a good idea to put encoded data like this 
into Nag. Another whups table seems messy, but I'm not coming up with 
anything better right now.

> The RULE tasks would encapsulate "data" for processing by specified
> methods, LATER... at the designated EVENT, such as a State change...

Right.

> Of course, it does create a requirement of one module upon another, which
> is probably undesirable, though not unprecedented.  Your call.  I'm
> willing to create a new whups table, and work forward with that...

Thinking about it a bit more, I really think this data belongs in Whups.

> It seems that you are moving rapidly ahead on
> Permissions/Notification.  I'll keep working on Turba/Nag/Hermes
> integration with Whups, as well as some Whups interface stuff that I'm
> almost ready to submit to you.  I'd like some feedback on the
> Turba-List  idea, if you don't mind, and I'd like to ask you to consider
> a generic method for triggering events when States change.  Whether it's
> Notification or it's Task Creation, or something else we haven't
> considered, it seems to me that it should get handled in an abstract
> manner, then become more concrete...

I agree. If you're asking me to implement it, well, that'll probably take 
me a bit. :)

-chuck

--
Charles Hagenbuch, <chuck@horde.org>
"People ask me all the time what it will be like living without otters."
 - Google, thanks to Harpers