Re: DTC competition with ISPMAN

Hi Atif,

long time no see!

Welcome back to ISPMan ;)

Yes indeed, I did a (MySQL based) database layout as a working draft for
 "ISPMan Next Generation" project, and I'm happy to share that.

As you may know, I'm trying myself with an ISPMan rewrite for some time
now, but am proceeding quite slowly due to many time constraints.
Actually, a real pity, because I've so many nice ideas... ;)

Starting a rewrite yourself is somewhat opening competition for me, but
maybe that gives some "kick" to get going again. ;)
My approach is Java/Perl/Webservice based. Currently, that is not yet
publicly shared, because I still change it a lot, as I'm experimenting
with various webservice alternatives.
Rather than considering this as fierce competition, I really would
prefer a cooperative side-by-side and eventually get the best "out
of both worlds".

You'll find the schema here:
https://sourceforge.net/tracker/index.php?func=3Ddetail&aid=3D1852150&group=
_id=3D8390&atid=3D358390
Consider this a working draft, that has not yet passed "reality-check".
Changes are probably inevitable, but it would be preferable if we could
align on a common schema within the ongoing projects.

Best regards,
Joerg


Atif Ghaffar wrote:
> Hi Joerg,
> =

> You once did a database entity diagram  mockup for ispman.
> Do you have it lying around somewhere for me to have a look again.
> =

> I am coming back to ISPman after 4 years of experience in ISPs and
> database/directory and will see if I can jumpstart a re-write
> =

> thanks
> =

> =

> On Mar 23, 2005 11:28 PM, J=F6rg Delker <[email protected]
> <mailto:[email protected]>> wrote:
> =

>     thomas-5VVOt45T8ASrG/[email protected] <mailto:thomas-5VVOt45T8ASrG/[email protected]> wrote:
> =

>     >http://www.gplhost.com/?rub=3Dsoftwares&sousrub=3Ddtc
>     <http://www.gplhost.com/?rub=3Dsoftwares&sousrub=3Ddtc>
>     >
>     >
>     >well, yeah, seriously nice with DTC
>     >ISPMAN using ldap, DTC using mysql
>     >
>     >for those who don't interested in setting up ldap server, mysql
>     might be
>     >alternative choice for you. but, isn't openldap performance is
>     faster than
>     >mysql ? (also, I know once openldap being setup, it is not easy to
>     break)
>     >
>     >that's your call, mysql or ldap :)
>     >
>     >
>     Thomas,
> =

>     don't think of this in terms of mysql vs. ldap or solely performance.
> =

>     The decision, whether to use mysql or ldap for the backend repository=
 is
>     mostly driven by functionality and your environment's demands.
>     MySQL is a classic RDBMS and thus very flexible when it comes to data
>     handling (esp. queries) and storage of structured data. Is is quite e=
asy
>     to store arbitrary data, such as Logs, Traffic, or other transaction
>     data.
>     Unfortunately, (My)SQL lacks connection to many (professional) softwa=
re
>     products, typically used within ISP business, since there is no open
>     protocol such systems could use.
> =

>     LDAP on the other hand is a *directory* service, providing fast access
>     to hierarchical structured "objects", while having limitations on wri=
te
>     performance and storage of arbitrary data.
>     Extending schemas to store "other" data can be quite painful and
>     requires good knowledge of LDAP specifications.
>     The reason why LDAP is actually very popular, esp. with ISPs, is the
>     open protocol and therefor the many systems that can connect to your
>     directory. Besides that it is very easy to make it highly available by
>     using replication.
> =

>     Actually, neither of those alone will fit the requirements of typical
>     ISPs, because you certainly need a fast directory service for all your
>     mail, calendar, web, ftp, samba, ... servers, which can't be provided=
 by
>     SQL servers.
>     On the other hand, you need easy storage for that arbitrary data, you
>     have to manage for your domains, which cries for a RDBMS.
> =

>     So...
>     regarding ISPMan, choosing LDAP was the right choice, because it open=
ed
>     up to many other applications out there, using all those valuable
>     directory data.
>     But with rising functionality and growing demands, it has become more
>     and more painful to extend the schema and store "other" data, such as
>     transactional data (logs, traffic, etc.).
>     We certainly can't drop LDAP, because this would mean imminent death =
to
>     ISPMan , but to have a future with this software I believe we need bo=
th,
>     LDAP *and* (My)SQL.
>     Maybe MySQL as the main repository, provisioning LDAP with all necess=
ary
>     entries... not clear about that yet.
> =

>     Comments welcome...
> =

>     Joerg
> =

> =

> =

> =

> -- =

> best regards
> Atif Ghaffar
> http://atif.ghaffar.googlepages.com
> =

> =

> ------------------------------------------------------------------------
> =

> -------------------------------------------------------------------------
> SF.Net email is sponsored by:
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services
> for just about anything Open Source.
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketpl=
ace
> =

> =

> ------------------------------------------------------------------------
> =

> _______________________________________________
> Ispman-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/ispman-users


-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace