[PEAK] protocols advice

[Duncan McGreggor]

I will dig in the various places you mentioned -- thanks! more below...

On Aug 16, 2004, at 10:53 PM, Phillip J. Eby wrote:

>> * If I need to start from the ground up, and we need to write our own 
>> interface/implementation, what would be the best way to start? Are 
>> there any examples or sandboxes where something like this/analogous 
>> to this has been done? I learn best by example ;-)
>
> If your data access needs are roughly "get some object via a known 
> key", then the current "Data Manager" framework is likely to suffice.

The "key" in my case would be the full path and filename of the RRD 
file... but you mention there is not a mechanism in place to do this. 
You think this is doable in any way?

> Take a look at the Wiki's "IntroToPeak" tutorial, which has very good 
> coverage of the system's current capabilities.  Lesson 1 covers basics 
> of PEAK applications, lesson 2 covers read-only data retrieval from 
> the file system, lesson 3 shows how to write data to the file system 
> and also how to use peak.storage.files.EditableFile to make the writes 
> transactional.  Lesson 4 moves the example to SQL-based storage, with 
> a more sophisticated domain model.

This was actually the first place I looked, a couple months ago. It's 
been a while, and you're right -- I should definitely re-visit this 
material, as there is much that will be helpful.

However, standard data apps are more sophisticated that what we need 
right now, though for the next phase, such an application model will be 
essential.

>> I am not sure what other information to provide, nor how clearly I 
>> have stated this information.
>
> Probably the interface you want to use would be helpful, and perhaps 
> an explanation of what "RRD files" are.  The term seems vaguely 
> familiar, but what it means is not coming immediately to mind.

Round Robin Database. It's the son of MRTG. Though it's used for 
networking stats/data gathering, RRDs are used for lots of other stuff 
as well... pretty much any measurable, 2D data. Typically, such data is 
graphed once stored. Each RRD file contains specific data for any given 
time-range. Data for a single day may have data points at 5 minute 
intervals. The same RRD data over a period of a week will be in a 
different file, averaged over some specified range (and thus with a 
lower resolution, keeping the file size small).

We would like the flexibility to not be limited to RRD, though; we'd 
like the option to store continuously expiring data, or averaging data 
in an RDBMS. For right now, though, another process creates and updates 
the RRDs; we just need to be able to read them (which means turning a 
query/search into full pathname).

d