Re: New module: FLV file parsing
Eric Wilhelm wrote: # from David Nicol # on Wednesday 30 November 2005 02:18 pm: isn't there a multimedia name space? name spaces per-product that is being supported make sense --- Flash::parseFLV perhaps? What else will appear in the Flash:: namespace? Will macromedia release a pure perl version? What all file format parsers and dumpers have in common is that they deal with File Formats. In a lot of cases, the only module that is going to be created is for that format. I'm working on CAD::DXF for now, but would rather name it FF::DXF, similarly with FF::SVG, FF::XAR, FF::PDF, etc. FF::FLV sounds best to me. In about 10 days time, I'm going to forget utterly that FF means File Formats. Does it need to be so terse? Tossing out another suggestion with this in mind: Parse::File::FLV David -- It's overkill of course, but you can never have too much overkill.
Re: New module: FLV file parsing
On 12/2/05, David Landgren [EMAIL PROTECTED] wrote: Eric Wilhelm wrote: What else will appear in the Flash:: namespace? Will macromedia release a pure perl version? In about 10 days time, I'm going to forget utterly that FF means File Formats. Does it need to be so terse? Tossing out another suggestion with this in mind: Parse::File::FLV The flood of modules that also pertain to manipulating flash files, now that Pagaltzis has smashed the levy. God only knows what they might look like. Flash::import::gif::animated, Flash::import::pdf, Flash::Dancer. -- David L Nicol Which is better, to burn out or to fade away? Refer to authorities from classical Roman, Greek and Chinese thought in your answer.
Re: FF:: namespace (was: New module: FLV file parsing)
# from David Landgren # on Friday 02 December 2005 08:25 am: In about 10 days time, I'm going to forget utterly that FF means File Formats. Does it need to be so terse? Considering the number of file formats which currently have toplevel names, FF:: isn't that terse. Besides, search results should mean that you _don't have to remember_ what FF means. SVG HTML XML PostScript (yeah, I know, let's pretend it's a format) PDF Pdf (heh) CSV POD ABI CSS GFL VRML YAML File::Format::RIFF is of course misplaced if you consider what other File:: modules do (typically fs queries/manipulation) and what File::Format might do given the use of formats in printf (and/or what the dos format command does :-) Then there is the issue of tucking them away under whatever toplevel namespace holds the domain with which that file format is associated such as Geo::GDAL Text::xSV Graphics::MNG Image::PNGwriter Apache::ConfigFile In some of these cases, putting the module under a namespace of related tools makes sense, but the problem is that the above two models are the only thing that new authors have as examples. Either you blaze a trail to a new TLNS or hide under an existing mumble (which may or may not be completely unrelated to the file format.) Tossing out another suggestion with this in mind: Parse::File::FLV But then we end up with Write::File::FLV ? Consider a distribution which reads and writes a given binary format (I'll call it GBF.) You want a parser, a writer, maybe a DOM, and/or a bit juggler, and you'll definitely need some constants and of course someone will eventually come along and write a ::Simple version. If we're going to use Parse::, then I'll assume that writers live in Write:: (since parsers are parsers, right?) Parse::File::GBF - Front end to GBF read/write interface Parse::File::GBF::Parser Parse::File::GBF::Bytes Parse::File::GBF::DOM Parse::File::GBF::Constants Parse::File::GBF::Simple Write::File::GBF - just a directory under this model Write::File::GBF::Simple Write::File::GBF::Stream But notice that Write::File::GBF probably requires Parse::File::GBF::Constants, etc. It's rather unsettling. Now consider the more comprehensible, discoverable single tree under FF:: FF::GBF - Front end to GBF read/write interface FF::GBF::Parser FF::GBF::Bytes FF::GBF::DOM FF::GBF::Constants FF::GBF::Writer FF::GBF::Simple FF::GBF::Writer::Stream Does that sound better? --Eric -- It is impossible to make anything foolproof because fools are so ingenious. --Murphy's Second Corollary --- http://scratchcomputing.com ---
Re: FF:: namespace (was: New module: FLV file parsing)
On Fri, December 2, 2005 12:50 pm, Eric Wilhelm said: Now consider the more comprehensible, discoverable single tree under FF:: FF::GBF - Front end to GBF read/write interface FF::GBF::Parser FF::GBF::Bytes FF::GBF::DOM FF::GBF::Constants FF::GBF::Writer FF::GBF::Simple FF::GBF::Writer::Stream Does that sound better? It's better than the other examples, which doesn't mean it is good. How about FileFormat:: ? FileFormat::GBF - Front end to GBF read/write interface FileFormat::GBF::Parser FileFormat::GBF::Bytes FileFormat::GBF::DOM FileFormat::GBF::Constants FileFormat::GBF::Writer FileFormat::GBF::Simple FileFormat::GBF::Writer::Stream Now you know just by looking at it what it means: GBF is a file format, and we have a parser, writer, stream, etc. for that format. Daniel T. Staal --- This email copyright the author. Unless otherwise noted, you are expressly allowed to retransmit, quote, or otherwise use the contents for non-commercial purposes. This copyright will expire 5 years after the author's death, or in 30 years, whichever is longer, unless such a period is in excess of local copyright law. ---
Re: FF:: namespace (was: New module: FLV file parsing)
On Fri, Dec 02, 2005 at 09:50:19AM -0800, Eric Wilhelm wrote: # from David Landgren # on Friday 02 December 2005 08:25 am: In about 10 days time, I'm going to forget utterly that FF means File Formats. Does it need to be so terse? Considering the number of file formats which currently have toplevel names, FF:: isn't that terse. Besides, search results should mean that you _don't have to remember_ what FF means. This is a good point, and sort of what I was thinking: If it can be found via search, who care's what it's called? It's sort of like domain names - once upon a time people might have thought to remember the name of a website, but now, who bothers? Just pop what you want in google... As long as the name isn't taken and it has some amount of logic, I doubt the name of a module makes any practical difference any more. It seems like the days of poring over proper module names should come to an end. *shrug* Just a thought. Austin
Re: New module: FLV file parsing
Eric Wilhelm writes: # from David Nicol # on Wednesday 30 November 2005 02:18 pm: isn't there a multimedia name space? ame spaces per-product that is being supported make sense --- Flash::parseFLV perhaps? What else will appear in the Flash:: namespace? It doesn't matter if nothing else appears there -- the module would still have a name that's readily understandable. What all file format parsers and dumpers have in common is that they deal with File Formats. Yes, but that isn't more relevant than the particular file format each deals with. For example, I'd be much more likely to first think that I'd be working with Flash files, and then realize that I need to parse them, than to start by thinking that I'm working with files that have a format, and only then that the format is Flash. In a lot of cases, the only module that is going to be created is for that format. And that causes what harm? I'm working on CAD::DXF for now, Cad is a well-known acronym. I have no use for anything cad-related in my life at the moment, so I know that I can safely ignore that module. But as it happens, referring to DXF in the context of cad is enough to prompt me into recollecting that .dxf is an AutoCad file extension. but would rather name it FF::DXF, Whereas if I saw that I wouldn't know what either set of letters mean; DXF is sufficiently meaningful in my brain to make me think of AutoCad without any context. And FF could be one of many things: recently I've seen it used to abbreviate Firefox in quite a few places; if I'd just been reading some music (or trying to solve a crossword) I might think of it meaning very loud. similarly with FF::SVG, FF::XAR, FF::PDF, etc. What does that achieve? Putting all the cad-related modules makes good sense to me, and similarly for other things. FF::FLV sounds best to me. I wouldn't have a clue what that means. I hadn't heard of FLV before this thread, and I wouldn't guess FF without this thread either. With Flash::FLV I still wouldn't know what FLV stands for, but I'd have a clue as to its context -- enough of a clue to know whether I'm interested in investigating the module further if it I see it in the 'recent uploads' list. Smylers -- May God bless us with enough foolishness to believe that we can make a difference in this world, so that we can do what others claim cannot be done.
Re: FF:: namespace (was: New module: FLV file parsing)
On Fri, Dec 02, 2005 at 03:31:48PM -0600, David Nicol wrote: On 12/2/05, Austin Schutz [EMAIL PROTECTED] wrote: As long as the name isn't taken and it has some amount of logic, I doubt the name of a module makes any practical difference any more. It seems like the days of poring over proper module names should come to an end. *shrug* Just a thought. Austin hmmm maybe I'll do like Jonothan Borofsky (http://www.borofsky.com/numbers.htm) and just number my modules from now on I think the interpreter might complain about that a bit- use 22; Perl v22.0.0 required (did you mean v22.000?)--this is only v5.8.6, stopped at -e line 1. :-) Austin
Re: FF:: namespace (was: New module: FLV file parsing)
I think the interpreter might complain about that a bit- use 22; Perl v22.0.0 required (did you mean v22.000?)--this is only v5.8.6, stopped at -e line 1. :-) Austin # perl -MModuleNumber22 -le 'print 1' Can't locate ModuleNumber22.pm in @INC (@INC contains: but maybe the series would better start at MN1 or maybe MNa so the name is more terse
Re: FF:: namespace (was: New module: FLV file parsing)
Sorry, that should have been $ perl -MModuleNumber::22 -le 'print 1' Can't locate ModuleNumber/22.pm in @INC
Re: New module: FLV file parsing
On Fri, Dec 02, 2005 at 04:04:11PM -0600, Chris Dolan wrote: So, I already published it as FLV::Info, but this discussion has convinced me that FileFormat::FLV is the best option. I may use that name for v0.02. My only hesitation is that nobody else seems to be using that top-level namespace at this time. The FF:: namespace is a terrible idea, in my opinion. I expect that it will be meaningless to the majority of module searchers. The argument that search makes names irrelevant is just silly. ..because? Ok, I want to do something with my flash file. I search for 'flash file'... Oh look, there's a flash file parser. Do I care what it's called? No. I concur that the module name is effectively meaningless, but I don't see that it makes any difference to the searcher. It's marginally helpful to have a useful name when including it in a module so code doesn't look like $flv = new ASDFsdafs::sjhsdlk, but beyond that, what tangible and practical difference does it make? If that were true, the practice of bouncing name ideas off this email list would cease, and I'd just name it FLV.pm. As I understand it there's some rationale for keeping the top level namespace small, so that would probably not be a good choice. Beyond that, name it what you will. I submit these long threads about which module name is better than some other similar name are a waste of time, and I do indeed suggest we take them off list as a general rule. Austin
Re: New module: FLV file parsing
Chris Dolan writes: So, I already published it as FLV::Info, but this discussion has convinced me that FileFormat::FLV is the best option. I still don't see what's to be gained from having all modules that deal with specific file-formats grouped together -- or more specifically why that makes more sense than grouping them in Cad:: or Graphics:: or Spreadsheet:: or whatever else they are actually useful for. The FF:: namespace is a terrible idea, in my opinion. Ditto. I expect that it will be meaningless to the majority of module searchers. Exactly -- even if you search by FLV, seeing FF::FLV in the results list doesn't help you at all. As for the Flash:: namespace, I don't think that's best. While FLV is primarily used in the Macromedia Flash Player ... However it's preferable for module names to be 'best fit' rather than 'pedantically accurate'. We want something that's meaningful to most people, even if technically it does more than that. ... it is not Flash but is a standalone video format. Well how about Video::FLV or Video::Format::FLV then? (Or even Video::Flash::FLV?) That would be like naming a CSS parsing module HTML::CSS::Parser, Yes, and I wouldn't object to that -- especially if CSS were a much less-well-known technology, such as when CSS clearly has utility beyond just HTML, despite its dominant usage. Yeah, but dominant usage is a great way of finding something. Anybody who wants to use CSS for something else is bound to know that HTML is its dominant usage. CSS has recently been used to format a book using Yes Logic's Prince ... but HTML was still used for the mark-up. Smylers -- May God bless us with enough foolishness to believe that we can make a difference in this world, so that we can do what others claim cannot be done.
Re: New module: FLV file parsing
* Eric Wilhelm [EMAIL PROTECTED] [2005-12-02 00:20]: What all file format parsers and dumpers have in common is that they deal with File Formats. In a lot of cases, the only module that is going to be created is for that format. I'm working on CAD::DXF for now, but would rather name it FF::DXF, similarly with FF::SVG, FF::XAR, FF::PDF, etc. I thought you were using “FF” as a shorthand for FileFormat on which I had no particular opinion, but following discussion indicates you actually proposed a literal “FF“ TLNS. In that case, I am strongly -1. It’s opaque without explaination, and even if you know what it means, you can’t meaningfully search on it. Both are terrible properties for a name. Regards, -- Aristotle “Like punning, programming is a play on words.” – Alan J. Perlis, “Epigrams in Programming”
Re: New module: FLV file parsing
* Smylers [EMAIL PROTECTED] [2005-12-02 22:10]:
Eric Wilhelm writes:
I'm working on CAD::DXF for now,
Cad is a well-known acronym. I have no use for anything
cad-related in my life at the moment, so I know that I can
safely ignore that module. But as it happens, referring to DXF
in the context of cad is enough to prompt me into recollecting
that .dxf is an AutoCad file extension.
Are we reinventing MIME types now? Let’s just stick with
Process::video::x_flv
Process::application::x_shockwave_flash
Process::image::x_dxf
Process::audio::mpeg
Process::image::png
Process::text::html
...
please.
Regards,
--
#Aristotle
*AUTOLOAD=*_;sub _{s/(.*)::(.*)/print$2,(,$\/, )[defined wantarray]/e;$1};
Just-another-Perl-hacker;
Searching and Browing (was: Re: New module: FLV file parsing)
Austin Schutz wrote: On Fri, Dec 02, 2005 at 04:04:11PM -0600, Chris Dolan wrote: So, I already published it as FLV::Info, but this discussion has convinced me that FileFormat::FLV is the best option. I may use that name for v0.02. My only hesitation is that nobody else seems to be using that top-level namespace at this time. The FF:: namespace is a terrible idea, in my opinion. I expect that it will be meaningless to the majority of module searchers. The argument that search makes names irrelevant is just silly. ..because? Ok, I want to do something with my flash file. I search for 'flash file'... Oh look, there's a flash file parser. Do I care what it's called? No. I concur that the module name is effectively meaningless, but I don't see that it makes any difference to the searcher. Two bad assumptions here: 1) the searcher always knows what words to search for, and 2) searching is an acceptable substitute for browsing. In this case of course, 'flash' is pretty obvious and searching for it should give one everything on CPAN, but in other cases this might not be true. For example, I had a little trouble with the RSS and Atom distinction, and had I been even more ignorant, I might have missed some useful modules. Taking the other side of the coin, browsing is much more useful when the module has a name that can catch the eye. Right now we only have two 'browsing' modes in CPAN, the Recent Arrivals list, and the all-but-useless Module List Chapter. I'd like to see true browsing, arranged in a tree structure (e.g., a list of top level names that one could click on, which would bring up a list of the TopLevelName::NextLevelNames, and so on). Granted that I'm using a non-existent feature [1] to demonstrate a point, but just how useful would an FF top level name be in this situation? It's marginally helpful to have a useful name when including it in a module so code doesn't look like $flv = new ASDFsdafs::sjhsdlk, but beyond that, what tangible and practical difference does it make? Choosing meaningful variable names in your code is considered good programming practice. Why wouldn't it be an equally good practice for naming modules? -john [1] In theory, this means that I just volunteered to work on this. Given that, does this idea interest anyone?
