Today [EMAIL PROTECTED] wrote:
>
> > I think the best would be if you started writing
> > documentation for the functions you are implementing /
> > planning as well as some general notes on the design ideas.
> >
> > To become realy useful, the abstraction may have to be pushed
> > even further ... keep in minde that as we go to a new cross
> > platform data format, the on disk structures will change, I
> > would like for that new abstraction to work with this.
> >
>
> My goal is to provide an alternative to directly invoking the C library
> filesystem functions (open, read, write) without needing to understand
> the data format.
>
> There are only a couple of areas where the file format does become an
> issue for such a low level API:
>
> - specifying the file size, so that mmap can be done behind the scenes
>
> - how to generalise madvise (my striping implementation potentially
> needs to extrapolate madvise to all the headers)
>
> - whether to treat different parts of the file in different ways (e.g.
> no striping for headers so that they can be mmaped, striping the RRAs
> behind the scenes)
>
> - how to (not) align the RRAs - this could actually be specified
> independently, although it is convenient to bundle this logic with the
> filesystem
>
> Rather than hammering out an API spec and then finding that it has to be
> changed, I would like to get my stripe implementation running this week,
> test it a little, and use feedback from that to guide decisions on the
> API.
:-) fine with me. I just dont like the trunk code to move all that
much at its heart without having a clear view as to where it is
going to, since it will be me who will be blamed later on if it
does not work ... but I'm sure if you finish your new idea first
you will also gain some insights which will come in handy when you
come back to the normal rrdtool code.
cheers
tobi
> Regards,
>
> Daniel
>
> _______________________________________________
>
> This e-mail may contain information that is confidential, privileged or
> otherwise protected from disclosure. If you are not an intended recipient of
> this e-mail, do not duplicate or redistribute it by any means. Please delete
> it and any attachments and notify the sender that you have received it in
> error. Unless specifically indicated, this e-mail is not an offer to buy or
> sell or a solicitation to buy or sell any securities, investment products or
> other financial product or service, an official confirmation of any
> transaction, or an official statement of Barclays. Any views or opinions
> presented are solely those of the author and do not necessarily represent
> those of Barclays. This e-mail is subject to terms available at the following
> link: www.barcap.com/emaildisclaimer. By messaging with Barclays you consent
> to the foregoing. Barclays Capital is the investment banking division of
> Barclays Bank PLC, a company registered in England (number 1026167) with its
> registered office at 1 Churchill Place, London, E14 5HP. This email may
> relate to or be sent from other members of the Barclays Group.
> _______________________________________________
>
>
--
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
http://it.oetiker.ch [EMAIL PROTECTED] ++41 62 775 9902 / sb: -9900
_______________________________________________
rrd-developers mailing list
rrd-developers@lists.oetiker.ch
https://lists.oetiker.ch/cgi-bin/listinfo/rrd-developers
