I have several tidbits here and there which are part of a larger project, but
which are useful on their own. These include a webcache class that stores
content in an LRU and tries to do the right thing regarding expired, etag,
and last_modified HTTP header items, and a library built around tmail to make
sending MIME emails easier.
Both of these were originally part of IOWA, but have been recently converted
into standalone libraries. Should they get their own projects at Rubyforge,
or should I just hang them off the IOWA project a seperate download?
I have a pretty sizable project that is a collection of just such
useful "mini-libs". Would you like to host them there? I'd be very
happy to consder them.
I think the best idea is to host them in the same project page. That
way people will know that the libraries are part of IOWA. Just make
sure that ppl doesn't get confused with too many different file
releases.
···
On 8/29/05, Kirk Haines <khaines@enigo.com> wrote:
I have several tidbits here and there which are part of a larger project, but
which are useful on their own. These include a webcache class that stores
content in an LRU and tries to do the right thing regarding expired, etag,
and last_modified HTTP header items, and a library built around tmail to make
sending MIME emails easier.
Both of these were originally part of IOWA, but have been recently converted
into standalone libraries. Should they get their own projects at Rubyforge,
or should I just hang them off the IOWA project a seperate download?
I would do the latter. That's more or less what I've done with both
Ruwiki and PDF::Writer as I've added mini-libs there, until those libs
grow up enough to demand their own space (which, so far, none of them
have ;).
-austin
···
On 8/29/05, Kirk Haines <khaines@enigo.com> wrote:
I have several tidbits here and there which are part of a larger project, but
which are useful on their own. These include a webcache class that stores
content in an LRU and tries to do the right thing regarding expired, etag,
and last_modified HTTP header items, and a library built around tmail to make
sending MIME emails easier.
Both of these were originally part of IOWA, but have been recently converted
into standalone libraries. Should they get their own projects at Rubyforge,
or should I just hang them off the IOWA project a seperate download?
I'm a bit paranoid about namespace pollution. So, everything that goes into
IOWA is in an Iowa:: namespace. So, the database connection pool is
Iowa::DbPool. The web cache class is Iowa::Webcache and the LRU class that
it uses is Iowa::LRUCache. And so on.
Does anyone see any problem with keeping these in that Iowa:: namespace when
released as standalone libraries? Keeping, for example, the webcache, under
Iowa:: makes sure that it won't butt heads with someone else's web cache.
Just calling it 'class Webcache', though, would.
Or should it be released as nothing more than a class file without any
installer, leaving it up to the user to make sure it doesn't butt heads with
something else? Anyone out there who might use this who has an opinion?
Thanks,
Kirk Haines
···
On Monday 29 August 2005 8:41 am, Austin Ziegler wrote:
I would do the latter. That's more or less what I've done with both
Ruwiki and PDF::Writer as I've added mini-libs there, until those libs
grow up enough to demand their own space (which, so far, none of them
have ;).
I'm a bit paranoid about namespace pollution. So, everything that goes into
IOWA is in an Iowa:: namespace. So, the database connection pool is
Iowa::DbPool. The web cache class is Iowa::Webcache and the LRU class that
it uses is Iowa::LRUCache. And so on.
Does anyone see any problem with keeping these in that Iowa:: namespace when
released as standalone libraries? Keeping, for example, the webcache, under
Iowa:: makes sure that it won't butt heads with someone else's web cache.
Just calling it 'class Webcache', though, would.
Or should it be released as nothing more than a class file without any
installer, leaving it up to the user to make sure it doesn't butt heads with
something else? Anyone out there who might use this who has an opinion?
My first thought is to keep it in Iowa:: if it's going to stay in synch
with Iowa versions, and to make it separate if it's going to diverge.
Or should it be released as nothing more than a class file without any installer, leaving it up to the user to make sure it doesn't butt heads with something else? Anyone out there who might use this who has an opinion?
If I can include it with
require 'webcache'
I would expect Webcache.new to work.
If I have to include it with
require 'iowa/webcache'
I would expect to have to prefix Iowa:: to the namespace. This would also imply to me that it isn't really standalone....
I'm not a Ruby authority by any means; is it possible to grab a naked module (e.g. something that imports directly into your namespace) and wrap it in a module? If so, then your fear of polluting the namespace is overcautious. This doesn't work, but you can see my intent:
···
------------------------------
class Webcache
#...our Webcache class
end
# Iowa's Webcache imports directly, conflicting with our Webcache
# class. Wrap it in IowaWebcache
module IowaWebcache
# this doesn't work--require seems to import directly into top-level space
require 'webcache'
end
Related:
- How can you achieve the desired result above, i.e. pushing an existing module down into another module?
- How can you reverse it, importing the contents of a module into the current namespace? (e.g. Python's "import from" syntax)
If the end-user can manipulate the modules and namespaces freely, then my suggestion is to put the code in the most *convenient* place possible. Later users can pack it away in another namespace if they feel the need.
-dB
--
David Brady
ruby-talk@shinybit.com
Grizzled C++/Python/Perl hacker. New to Ruby. Take my Ruby statements with the appropriate amount of salt.
I'm having a really surreal day... OR AM I?
That's a bit of a good question, and I'm not the *best* person to ask,
as I have claimed a couple of high-level namespaces The simple answer
is "it depends."
* With MIME::Types, I basically claimed MIME::Type and MIME::Types and
forced ::MIME to be a module if anyone uses it. (But that's not a
subproject. However, if I ever *do* get around to doing the libmagic
stuff, it'll probably be MIME::Magic.)
* With Diff::LCS, I forced Diff to be a module, but chose to be more
specific.
* I went further with Archive::Tar::Minitar (obviously).
* PDF::Writer is perhaps the biggest claim, and it's not going to get
much better unless I come up with a cool project name to replace it. I
will be releasing PDF::Core, PDF::Writer, and PDF::Reader, all. I have
several utility items (PDF::Charts::*, PDF::SimpleTable, etc.) that
have sort of claimed space.
* color-tools has claimed the entire Color namespace (which, frankly, I
don't mind ;), but makes it a bit harder for others to use ::Color as
anything other than a module, and I "own" Color::RGB and Color::CMYK
and others as a result of it.
I can't see having done any of these any other way, though, since
although color-tools was originally made to support PDF::Writer, I want
it to be the premier colour conversion and management library in the
Ruby world.
On the other hand, I'm working on a different library (also an offshoot
of PDF::Writer) that I've chosen an entirely different name for (and
even that may change if someone takes the name I've chosen or I find a
better one).
-austin
···
On 8/29/05, Kirk Haines <khaines@enigo.com> wrote:
On Monday 29 August 2005 8:41 am, Austin Ziegler wrote:
I would do the latter. That's more or less what I've done with both
Ruwiki and PDF::Writer as I've added mini-libs there, until those
libs grow up enough to demand their own space (which, so far, none of
them have ;).
Okay, now, a related question.
I'm a bit paranoid about namespace pollution. So, everything that
goes into IOWA is in an Iowa:: namespace. So, the database connection
pool is Iowa::DbPool. The web cache class is Iowa::Webcache and the
LRU class that it uses is Iowa::LRUCache. And so on.
Does anyone see any problem with keeping these in that Iowa::
namespace when released as standalone libraries? Keeping, for
example, the webcache, under Iowa:: makes sure that it won't butt
heads with someone else's web cache. Just calling it 'class Webcache',
though, would.
Or should it be released as nothing more than a class file without any
installer, leaving it up to the user to make sure it doesn't butt
heads with something else? Anyone out there who might use this who
has an opinion?
The simple answer