Very Computer

by **Kurt Webe** » Thu, 25 Apr 2002 06:27:26

I'm writing a newsreader, and I had an idea for a highly modularized design
as follows:

A NNTP module that would communicate with the server...this would be
essential and the only standard module (although the distribution would
ship with every module, this would be the only one that cannot be taken out
and replaced)

A config file module, which could have several different interchangeable
versions so you could use whatever syntax and directives you liked in your
config files

A UI module, so you could have any sort of user interface design you liked

A scripting module, so you could implement whatever scripting language you
wanted (or create your own) for use within the newsreader

An article-storage module, so you could use whatever format you desired to
store your articles and newsgroup list

These would all communicate via FIFOs [1], and the idea is that you can
find modules of each type that worked in whatever way you wanted (or even
write your own) and drop them in interchangeably...each module would be
totally separate from the others, and would communicate via the FIFOs via a
standardized protocol.

My question is, am I taking this whole modularization thing too far?

--
Kurt Weber

ROW Software and Web Design
http://www.rowsw.com

by **Alex Mitrofano** » Thu, 25 Apr 2002 06:54:50

> I'm writing a newsreader, and I had an idea for a highly modularized design
> as follows:

> A NNTP module that would communicate with the server...this would be
> essential and the only standard module (although the distribution would
> ship with every module, this would be the only one that cannot be taken out
> and replaced)

[...]
> These would all communicate via FIFOs [1], and the idea is that you can
> find modules of each type that worked in whatever way you wanted (or even
> write your own) and drop them in interchangeably...each module would be
> totally separate from the others, and would communicate via the FIFOs via a
> standardized protocol.

> My question is, am I taking this whole modularization thing too far?

Why don't you want to use more traditional modularization approach using
dlopen() call? That would be easier, cleaner, and faster.

--
Alex Mitrofanov
Brainbench MVP for C++
http://www.brainbench.com

by **Santhosh Kud** » Thu, 25 Apr 2002 11:24:48

> > I'm writing a newsreader, and I had an idea for a highly modularized design
> > as follows:

> > A NNTP module that would communicate with the server...this would be
> > essential and the only standard module (although the distribution would
> > ship with every module, this would be the only one that cannot be taken out
> > and replaced)

> [...]
> > These would all communicate via FIFOs [1], and the idea is that you can
> > find modules of each type that worked in whatever way you wanted (or even
> > write your own) and drop them in interchangeably...each module would be
> > totally separate from the others, and would communicate via the FIFOs via a
> > standardized protocol.

> > My question is, am I taking this whole modularization thing too far?

> Why don't you want to use more traditional modularization approach using
> dlopen() call? That would be easier, cleaner, and faster.

I would just add that, maybe you might want to abstract your
communication protocol into a seperate module. Today its FIFO`s
tomorrow it might be something else, so you might find it easier to
accomodate such changes.

Santhosh

by **GoogleF** » Thu, 25 Apr 2002 17:14:20

> I would just add that, maybe you might want to abstract your
> communication protocol into a seperate module. Today its FIFO`s
> tomorrow it might be something else, so you might find it easier to
> accomodate such changes.

> Santhosh

I would suggest that FIFOs are a bad idea. They have limited buffering
and if you suffer any bottlenecks anywhere then they are likely to be
a pain in the butt.

If you want speed, then multithreading and/or shared memory for
communication so you can create your own buffering layer.

Given you want to abstract things, then the poster above is right -
modularise your I/O mechanism so you can go for things like FIFO or
TCP or whatever.

Whether you use dlopen() or not is not really an issue as you get your
design off the ground.

by **Kurt Webe** » Fri, 26 Apr 2002 06:37:06

>> I would just add that, maybe you might want to abstract your
>> communication protocol into a seperate module. Today its FIFO`s
>> tomorrow it might be something else, so you might find it easier to
>> accomodate such changes.

>> Santhosh

> I would suggest that FIFOs are a bad idea. They have limited buffering
> and if you suffer any bottlenecks anywhere then they are likely to be
> a pain in the butt.

> If you want speed, then multithreading and/or shared memory for
> communication so you can create your own buffering layer.

> Given you want to abstract things, then the poster above is right -
> modularise your I/O mechanism so you can go for things like FIFO or
> TCP or whatever.

Well, the problem with TCP is since the configuration files are read in a
separate module, then the TCP port used for communication (at least until
the config file module is loaded and the config files are read) will have
to be hard-coded; thus, one may run into problems if that port is already
in use when the newsreader is started.

--
Kurt Weber

ROW Software and Web Design
http://www.rowsw.com

by **Kurt Webe** » Fri, 26 Apr 2002 07:30:44

> Given you want to abstract things, then the poster above is right -
> modularise your I/O mechanism so you can go for things like FIFO or
> TCP or whatever.

Another problem I see with that is how will the modules themselves know
whether to use TCP/IP, FIFOs, or whatever other form of IPC that one
chooses to use?

--
Kurt Weber

ROW Software and Web Design
http://www.rowsw.com

by **Santhosh Kud** » Fri, 26 Apr 2002 21:49:59

> > Given you want to abstract things, then the poster above is right -
> > modularise your I/O mechanism so you can go for things like FIFO or
> > TCP or whatever.

> Another problem I see with that is how will the modules themselves know
> whether to use TCP/IP, FIFOs, or whatever other form of IPC that one
> chooses to use?

The OP states that the configuration file reading functions are
modularized into a seperate module. But the OP has not mentioned
anything about the order of execution.

If config files arent read first then the problem becomes highly
challenging and difficult, given the trade off of complexity versus
flexibility in my opinion :-), perhaps reading config files first
might be a good idea.

Well it could do roughly something like this,

main()
{
read_news()

Quote:}

read_news()
{
Commlink *comm ;

if(!is_comm_created(comm))
{
comm = comm_create() ;
comm = comm_get_parameters(config_file) ;
comm = comm_get_data() ;
comm = comm_close() ;
}

Quote:}

The code isnt great, but its just to illustrate an idea.

Cheers
santhosh

by **Santhosh Kud** » Fri, 26 Apr 2002 22:03:22

> > Given you want to abstract things, then the poster above is right -
> > modularise your I/O mechanism so you can go for things like FIFO or
> > TCP or whatever.

> Another problem I see with that is how will the modules themselves know
> whether to use TCP/IP, FIFOs, or whatever other form of IPC that one
> chooses to use?

Oops, I am getting a little blind these days. I didnt realize that you
were the OP. So your question stands. My apologies.

But I still think you would have to read whatever config info you need
from a file. as the previous post suggests. But one further question
is why is there a precedence on the module loading. Generally,
configurations are read first AFAIK to acquire context and state of
the program.

Cheers,
Santhosh

by **Kurt Webe** » Sat, 27 Apr 2002 08:19:08

>> > Given you want to abstract things, then the poster above is right -
>> > modularise your I/O mechanism so you can go for things like FIFO or
>> > TCP or whatever.

>> Another problem I see with that is how will the modules themselves know
>> whether to use TCP/IP, FIFOs, or whatever other form of IPC that one
>> chooses to use?

> Oops, I am getting a little blind these days. I didnt realize that you
> were the OP. So your question stands. My apologies.

> But I still think you would have to read whatever config info you need
> from a file. as the previous post suggests. But one further question
> is why is there a precedence on the module loading. Generally,
> configurations are read first AFAIK to acquire context and state of
> the program.

Yes, and the order in which the modules are loaded is listed in my first
post. Even if the config files are read absolutely first (before the NNTP
module is loaded), however, the problem remains--how are the modules
supposed to communicate with the config module to find out which method
they're supposed to use to communicate.

Well, now that I think of it, the config module could simply set an
environment variable to tell the other modules how to communicate with
it...and if it's TCP/IP, then also what port to use.

--
Kurt Weber

ROW Software and Web Design
http://www.rowsw.com

by **Santhosh Kud** » Sat, 27 Apr 2002 16:57:01

> >> > Given you want to abstract things, then the poster above is right -
> >> > modularise your I/O mechanism so you can go for things like FIFO or
> >> > TCP or whatever.

> >> Another problem I see with that is how will the modules themselves know
> >> whether to use TCP/IP, FIFOs, or whatever other form of IPC that one
> >> chooses to use?

> > Oops, I am getting a little blind these days. I didnt realize that you
> > were the OP. So your question stands. My apologies.

> > But I still think you would have to read whatever config info you need
> > from a file. as the previous post suggests. But one further question
> > is why is there a precedence on the module loading. Generally,
> > configurations are read first AFAIK to acquire context and state of
> > the program.

> Yes, and the order in which the modules are loaded is listed in my first
> post. Even if the config files are read absolutely first (before the NNTP
> module is loaded), however, the problem remains--how are the modules
> supposed to communicate with the config module to find out which method
> they're supposed to use to communicate.

> Well, now that I think of it, the config module could simply set an
> environment variable to tell the other modules how to communicate with
> it...and if it's TCP/IP, then also what port to use.

Well I assume by modules you mean Services...? or am I missing
something here. Because if they are libraries, then its just a matter
of ensuring an interface. Then the only comm service you need is for
the nntp reader to communicate with the NNTP server.

If I assume that these are services, then, the problem boils down to
how will the config and the comm module communicate.

The comm module needs to get the config information. As far as the
other modules are concerned they are just users of a service. So their
interface to the service will not change. When the comm service inits
it will bring up whatever communication service it requires.

Well as you suggest, between the two, a Env Variable might be a good
idea. Or else, you can have a default comm interface to fall back on
and init the connection between the config and comm modules, before
switching to the comm service specified in the config file.

HTH
Cheers
Santhosh

Very Computer

Design Question--am I going too far with this?

Design Question--am I going too far with this?

Design Question--am I going too far with this?

Design Question--am I going too far with this?

Design Question--am I going too far with this?

Design Question--am I going too far with this?

Design Question--am I going too far with this?

Design Question--am I going too far with this?

Design Question--am I going too far with this?

Design Question--am I going too far with this?

Design Question--am I going too far with this?