All of lore.kernel.org
 help / color / mirror / Atom feed
* mlmmj code refactoring, for ease of reuse
@ 2006-05-28 18:49 Søren Boll Overgaard
  2006-05-29  8:19 ` Jakob Hirsch
                   ` (3 more replies)
  0 siblings, 4 replies; 5+ messages in thread
From: Søren Boll Overgaard @ 2006-05-28 18:49 UTC (permalink / raw)
  To: mlmmj

Hi,

I wasn't able to find any posts related to this topic, so I am posting to the
list for comments.

I would like to create a convenient system for provisioning mlmmj mailinglists
across a network. That is, I would like to be able to connect to a daemon on a
given host, and tell it to create a list, subscribe a user, unsubscribe a user,
etc. This would also make it easier to create user interfaces for manipulating
mlmmj.

In order to minimize the work involved, I intend to write the thing in C, and 
I was hoping to reuse mlmmj code, to do most of the actual work.
Unfortunately, lots of mlmmj functionality is hidden away inside various
main() methods, making it quite hard to export the functionality for easy
access from other code. 

Do you have any suggestions for accessing this functionality, short of copying
the code verbatim into my own source files? 

Thanks.

-- 
Søren O.

"Oh, bother" said the Borg, "we've assimilated Pooh".

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: mlmmj code refactoring, for ease of reuse
  2006-05-28 18:49 mlmmj code refactoring, for ease of reuse Søren Boll Overgaard
@ 2006-05-29  8:19 ` Jakob Hirsch
  2006-05-29  9:08 ` Søren Boll Overgaard
                   ` (2 subsequent siblings)
  3 siblings, 0 replies; 5+ messages in thread
From: Jakob Hirsch @ 2006-05-29  8:19 UTC (permalink / raw)
  To: mlmmj

Søren Boll Overgaard wrote:

> I would like to create a convenient system for provisioning mlmmj
> mailinglists across a network. That is, I would like to be able to connect
> to a daemon on a given host, and tell it to create a list, subscribe a
> user, unsubscribe a user, etc. This would also make it easier to create
> user interfaces for manipulating mlmmj.
>
> In order to minimize the work involved, I intend to write the thing in C,

I think coding in C does usually not minimize the work. Instead of reusing
the mlmmj code (and therefore having to keep pace with new versions), I'd
rather do it The Unix Way: Write a simple wrapper script/programm (Perl,
Python, Ruby, $whatever, even in C that's no big deal) which reads
commands from a tcp socket or, even easier, reads from STDIN (so you can
use it with inetd), and invokes the corresponding mlmmj binary.
The only reason to do this in a single C programm would be performance,
but I guess you are not going to create thousands of lists per second.



^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: mlmmj code refactoring, for ease of reuse
  2006-05-28 18:49 mlmmj code refactoring, for ease of reuse Søren Boll Overgaard
  2006-05-29  8:19 ` Jakob Hirsch
@ 2006-05-29  9:08 ` Søren Boll Overgaard
  2006-06-11 21:11 ` Søren Boll Overgaard
  2006-06-17 12:21 ` Søren Boll Overgaard
  3 siblings, 0 replies; 5+ messages in thread
From: Søren Boll Overgaard @ 2006-05-29  9:08 UTC (permalink / raw)
  To: mlmmj

On Mon, May 29, 2006 at 10:19:35AM +0200, Jakob Hirsch wrote:
> Søren Boll Overgaard wrote:
> 
> > I would like to create a convenient system for provisioning mlmmj
> > mailinglists across a network. That is, I would like to be able to connect
> > to a daemon on a given host, and tell it to create a list, subscribe a
> > user, unsubscribe a user, etc. This would also make it easier to create
> > user interfaces for manipulating mlmmj.
> >
> > In order to minimize the work involved, I intend to write the thing in C,
> 
> I think coding in C does usually not minimize the work. Instead of reusing
> the mlmmj code (and therefore having to keep pace with new versions), I'd
> rather do it The Unix Way: Write a simple wrapper script/programm (Perl,
> Python, Ruby, $whatever, even in C that's no big deal) which reads
> commands from a tcp socket or, even easier, reads from STDIN (so you can
> use it with inetd), and invokes the corresponding mlmmj binary.
> The only reason to do this in a single C programm would be performance,
> but I guess you are not going to create thousands of lists per second.

You are right of course, as using execlp() is excactly how (sub, unsub, etc.) 
commands are executed inside mlmmj. 

Generally though, I think it would be nice if mlmmj exported a more developer
friendly C api, with functions like subscribe(), unsubscribe(), create_list(),
etc.  Perhaps even by means of a shared library? 

Anyway, I will look into the approach you are suggesting, probably based on
python.

Thanks for the input.

-- 
Søren O.

"Oh, bother" said the Borg, "we've assimilated Pooh".

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: mlmmj code refactoring, for ease of reuse
  2006-05-28 18:49 mlmmj code refactoring, for ease of reuse Søren Boll Overgaard
  2006-05-29  8:19 ` Jakob Hirsch
  2006-05-29  9:08 ` Søren Boll Overgaard
@ 2006-06-11 21:11 ` Søren Boll Overgaard
  2006-06-17 12:21 ` Søren Boll Overgaard
  3 siblings, 0 replies; 5+ messages in thread
From: Søren Boll Overgaard @ 2006-06-11 21:11 UTC (permalink / raw)
  To: mlmmj

Replying to my own post,

On Mon, May 29, 2006 at 11:08:56AM +0200, Søren Boll Overgaard wrote:
> 
> Generally though, I think it would be nice if mlmmj exported a more developer
> friendly C api, with functions like subscribe(), unsubscribe(), create_list(),
> etc.  Perhaps even by means of a shared library? 
> 
> Anyway, I will look into the approach you are suggesting, probably based on
> python.

I have all but completed writing a server for remotely managing an mlmmj
installation. The server is written in python and uses the mlmmj-* binaries for
functionality whereever possible.

Additionally, I've written a fairly basic php client.

I would greatly appreciate it if someone would contribue clients written in
other languages. In my opinion that would be the best way to thoroughly test
the server before I publish the code.

If you are interested, please get in touch with me directly and we can
coordinate.

Thanks.

-- 
Søren O.

"Oh, bother" said the Borg, "we've assimilated Pooh".

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: mlmmj code refactoring, for ease of reuse
  2006-05-28 18:49 mlmmj code refactoring, for ease of reuse Søren Boll Overgaard
                   ` (2 preceding siblings ...)
  2006-06-11 21:11 ` Søren Boll Overgaard
@ 2006-06-17 12:21 ` Søren Boll Overgaard
  3 siblings, 0 replies; 5+ messages in thread
From: Søren Boll Overgaard @ 2006-06-17 12:21 UTC (permalink / raw)
  To: mlmmj

On Sun, Jun 11, 2006 at 11:11:07PM +0200, Søren Boll Overgaard wrote:
> > 
> > Generally though, I think it would be nice if mlmmj exported a more developer
> > friendly C api, with functions like subscribe(), unsubscribe(), create_list(),
> > etc.  Perhaps even by means of a shared library? 
> > 
> > Anyway, I will look into the approach you are suggesting, probably based on
> > python.
> 
> I have all but completed writing a server for remotely managing an mlmmj
> installation. The server is written in python and uses the mlmmj-* binaries for
> functionality whereever possible.
> 
> Additionally, I've written a fairly basic php client.
> 

I've made the code available at
http://soren.overgaard.org/cgi-bin/index?t=mlmmjadmd if anyone is interested.
It appears to be working as intended, though I can't be completely sure, since
my test script doesn't yet test all available functionality.

-- 
Søren O.

"Oh, bother" said the Borg, "we've assimilated Pooh".

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2006-06-17 12:21 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2006-05-28 18:49 mlmmj code refactoring, for ease of reuse Søren Boll Overgaard
2006-05-29  8:19 ` Jakob Hirsch
2006-05-29  9:08 ` Søren Boll Overgaard
2006-06-11 21:11 ` Søren Boll Overgaard
2006-06-17 12:21 ` Søren Boll Overgaard

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.