[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: The Split? (was Re: LuaSocket http ftp smpt...)
- From: Diego Nehab <diego@...>
- Date: Thu, 3 Feb 2005 14:22:50 -0500 (EST)
Hi,
> Talking of splitting... from my perspective, LuaSocket is either a
> misnomer or it tries to do too many things at the same time...
The name LuaNet was taken, NetLib was too... :)
> In a sense, LuaSocket is really 4 generic libraries rolled into one.
> Splitting them along those functional lines would seriously increase
> reuse and general usefulness and could even be viewed as the foundation
> of a standard set of Lua packages :)
Each module makes its dependencies explicit with require().
LuaSocket core: no dependencies
URL, LTN12: no dependencies
MIME core: no dendencies
MIME: MIME core and LTN12.
SMTP: MIME, LTN12, and LuaSocket core.
FTP: LTN12, URL, and LuaSocket core.
HTTP: MIME, LTN12, URL, and LuaSocket core.
I do want to distribute these things as separate libraries. It would
simply be a maintenance, distribution, and installation nightmare. How
would the reuse be increased? Things are already modular. Perhaps the
same effect can be achieved by better advertisement?
> (1) The core of LuaSocket, as I understand it, is Socket, TCP and UDP.
> That should be all. Nothing more. Nothing less :)
I would say that the core deals with the transport layer. Whatever case
it might be. I always had plans to support local domain sockets (which
I already distribute as a sample), pipes, named pipes, so on and so
forth. These things have to be implemented in C.
> (2) The netlib stack includes application level protocol build on top
> of the core Socket functionality: DNS, FTP, HTTP, SMTP, URL.
I would leave DNS in the core, since there is not much you can do with
TCP/IP and UDP without DNS.
> (3) A generic MIME handling facility.
>
> (4) LTN12 as a little world in itself. Filters, sources, sinks, pumps
> are useful generic concept which could be used in many different
> contexts.
These two are already completely independent from the rest of LuaSocket.
However, other LuaSocket modules depend on them, and were the original
motivation for their development.
Regards,
Diego.