| Subject: | POE::API::Ctl |
POE needs a way of managing various bits of data about internal
configuration and operation. this can be useful for introspection or for
replacing/augmenting systems like the ASSERT and TRACE constants we have
in place now.
in irc, rocco and i drafted up a system that smells an awful lot like
proc/sysctl/perl's MAGIC. for posterity, i've attached the relevant log
to this ticket.
the idea is to store, via a module named POE::Resource::Controls, a
fairly arbitrary hash of data inside the kernel. this would be exposed
to the user via a module named POE::API::Ctl, sysctl style. the user
should be able to write to a certain subset of the data.
<@sungo> LotR: you're right. there was a set of LOOP variables way back when
<@dngnand> They had to die.
<@sungo> why?
<@dngnand> They were part of the loop loader that required hardcoding in POE::Kernel.
<@sungo> can we store the name of the loop module we ended up loading inside hte kernel sompelace?
<@dngnand> I think we do, at least temporarily.
<@sungo> there's a lexical in the "figure out which loop to run" code block but we dont keep it
<@dngnand> If it's really useful, I vote for package lexical and accessor.
<@sungo> so, adding this to the kernel internals means yet another constant on the pile
<@sungo> can we have a magic heap of misc info about the internals?
<@dngnand> I'm not sure I see the use in it. S'not like $user code doesn't know which loop it's loading.
<@sungo> they may not
<@sungo> introspection is a good idea
<@dngnand> Ok.
<@sungo> and i have a lot of introspection type requests to make ;)
<@dngnand> Magic heap = registry?
<@sungo> not necessarily
<@sungo> i was thinking a hash bucket inside the kernel.
<@dngnand> There's already something of a magic heap in the statistics resource module.
<@sungo> labelled as "misc shit here. dont use for important things"
<@sungo> like /proc :P
<@dngnand> Writable?
<@sungo> by who?
<@dngnand> Should users be allowed to write in it?
<@sungo> i wouldnt think so
<@sungo> my thought would be to have a get_attribute() method or something
<@dngnand> It might be useful for frobbables, sort of sysctl-like.
<@sungo> we could certainly do that
<@dngnand> Two tiers of debugging flags. The current constants that enable/disable tracing and asserting, and a set of runtime checks in the magic hash thing.
<@sungo> right. things needed at compile time and things which are not
<@dngnand> If the constants aren't on, the magic hash checks don't happen.
<@dngnand> ASSERTS and $self->magic("assert/gc") and do { die if $blah }
<@sungo> doable
<@sungo> shall i code up magic?
<@dngnand> Statistics could be stored in it, too.
<@sungo> yup
<@sungo> i keep calling this magic btw because its the same purpose and structure as the MAGIC section inside perl scalars :)
<@dngnand> A nice interface might replace the sub ASSERT_FOO () { 1 } toggles, too.
<@sungo> shall i code this up as POE::Ctl? :)
<@dngnand> Does it fall outside POE::Resource:: ?
<@sungo> sort of
<@sungo> it doesnt fall outside of POE::API tho
<@sungo> if you're wanting to expose this to the users, then part of it should be in POE::API
<@dngnand> I have the feeling that it should be broken into an API and a Resource class.
<@sungo> yup
<@sungo> the actual data structures inside a Resource class
<@sungo> and the api in a ... well .. API class :)
<@dngnand> Hmm.
<@dngnand> I was thinking of a pragma to combine the compile- and run-time flags. use POE::assert qw(gc); # for example
<@sungo> sure. could use the API internally :)
<@dngnand> Ok, I think that's feasable. You're "it" on this one. Gonna tell the list about it first?
<@sungo> once we have the low level stuff grooving, we can add all kinds of high level fun if you'd like :)
<@sungo> i'm going to paste this convo into the rt ticket that spawned it first
<@sungo> so i can reference it in the list email
<@sungo> sound good?
<@dngnand> Yep.
<@sungo> awesome