POE-Devel-ProcAlike

 view release on metacpan or  search on metacpan

README  view on Meta::CPAN

    have to figure out how to create a singleton and use that if your PoCo
    has been spawned N times. The reasoning behind this is to have a
    "uniform" filesystem that would be valid across multiple invocations. If
    we allowed module authors to register any name, then we would end up
    with possible collisions and wacky schemes like "$pkg$ses->ID" as the
    name...

    Also, here's a tip: you don't have to implement the entire
    Filesys::Virtual::Async API because FUSE doesn't use them all! The ones
    you would have to do is: rmtree, scandir, move, copy, load, readdir,
    rmdir, mkdir, rename, mknod, unlink, chmod, truncate, chown, utime,
    stat, write, open. To save even more time, you can subclass the
    Filesys::Virtual::Async::inMemory module and set readonly to true. Then
    you would have to subclass only those methods: readdir, stat, open.

  TODO
    *   tunable parameters

        Various people in #poe@magnet suggested having a system where we
        could do "sysctl-like" stuff with this filesystem. I'm not entirely
        sure what we can "tune" in regards to POE but if you have any ideas

lib/POE/Devel/ProcAlike.pm  view on Meta::CPAN

	My::Module::SubClass does a register, it will be mounted in:
	/modules/my-module-subclass

Furthermore, ProcAlike only allows each package to register once, so you have to figure out how to create a singleton
and use that if your PoCo has been spawned N times. The reasoning behind this is to have a "uniform" filesystem
that would be valid across multiple invocations. If we allowed module authors to register any name, then we would
end up with possible collisions and wacky schemes like "$pkg$ses->ID" as the name...

Also, here's a tip: you don't have to implement the entire L<Filesys::Virtual::Async> API because FUSE doesn't use
them all! The ones you would have to do is: rmtree, scandir, move, copy, load, readdir, rmdir, mkdir, rename, mknod,
unlink, chmod, truncate, chown, utime, stat, write, open. To save even more time, you can subclass the
L<Filesys::Virtual::Async::inMemory> module and set readonly to true. Then you would have to subclass only those
methods: readdir, stat, open.

=head2 TODO

=over 4

=item * tunable parameters

Various people in #poe@magnet suggested having a system where we could do "sysctl-like" stuff with this filesystem.

lib/POE/Devel/ProcAlike/ModuleInfo.pm  view on Meta::CPAN

# _rename

# _mknod

# _unlink

# _chmod

# _truncate

# _chown

# _utime

sub _stat {
	my( $self, $path ) = @_;

	# return generic info
	my ($atime, $ctime, $mtime, $size, $modes);
	$atime = $ctime = $mtime = time();
	my ($dev, $ino, $rdev, $blocks, $gid, $uid, $nlink, $blksize) = ( 0, 0, 0, 1, (split( /\s+/, $) ))[0], $>, 1, 1024 );

lib/POE/Devel/ProcAlike/POEInfo.pm  view on Meta::CPAN

# _rename

# _mknod

# _unlink

# _chmod

# _truncate

# _chown

# _utime

# helper to process ARRAY fs type
sub _stat_arraymode {
	my $file = shift;

	my $method = $fs{ $file }->[1];
	my $data = $fs{ $file }->[0]->$method();

lib/POE/Devel/ProcAlike/PerlInfo.pm  view on Meta::CPAN

# _rename

# _mknod

# _unlink

# _chmod

# _truncate

# _chown

# _utime

sub _stat {
	my( $self, $path ) = @_;

	# stating the root?
	if ( $path eq File::Spec->rootdir() ) {
		my ($atime, $ctime, $mtime, $size, $modes);
		$atime = $ctime = $mtime = time();