On Mon, Nov 11, 2002 at 12:17:46PM +0100, Jörg Ziefle wrote: > On Fri, Nov 08, 2002 at 07:47:15PM +0000, Tim Bunce wrote: > > Seems like a good fit for the new WebService:: category. > > > > But how does it relate to > > http://search.cpan.org/author/SAMV/Lingua-Translate-0.06/lib/Lingua/Translate.pm > > I wasn't aware of that module. Its purpose seems pretty similar to my > module (it uses the Babelfish service instead of the LEO one, which has > different pros and cons). Then again, this raises the question why that > module is not in WebService? :)
Actually it raises the opposite issue... A general guideline for modules is that they should be named for what they do not how they do it. So the "WebService" category should only be used where "what the module does" is closely related to the fact it uses a web service. > I had a thought about modifying my code to be a backend to > Lingua::Translate, but the Lingua::Translate frontend seems to be > designed specifically for the two available backends, so my interface > (resp. the interface that is needed to provide the functionality I want) > doesn't fit in there very well right now. In other words, the change > would require considerable changes in Lingua::Translate first. As the > POD of Lingua::Translate states: > > --- > =head1 BUGS/TODO > > [...] > > Need to formalise and define the "Interface" that the back-end modules > adhere to. > --- > > Therefore, it seems to be reasonable to go with one of > > * WebService::LEO <-- simplicity > * WebService::DictLEO <-- purpose visible in name > (* WebService::Dict::LEO) <-- w/ same implications as stated above Given what I've said above and what I understand of your module it seems like Lingua:: would be the best category to use. So I'd suggest something like Lingua::LEOTranslate, or perhaps a Lingua::Translate::LEO module that offers both a minimal plugin to Lingua::Translate and also a more full-features API for applications that "use Lingua::Translate::LEO;" directly. Tim.
