I'm afraid you're going to have to be a bit more specific --
which portions of IRM do you think should be integrated with
eGroupWare? Users and passwords? Does eGroupWare have a
ticketing module, or some internal way of associating users
with computers? Having never used it, I don't know what
it's capable of, nor do I have any experience programming
to/for it.
Also, do you have any references (links to the eGroupWare
site, for instance) which document how eGW does what you
want done, so it's easier for us to develop against it?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
eGW has trouble ticket system the same of IRM, but not have anything
for control / stock machines. eGW is good for comunities and companies
it has a lot of modules with same user/password and same url. You have
on it trouble ticket, wiki, diary, ... and why not a Information Resource ?
You can see all about eGW on egroupware.org
Benefits for IRM:
Thousands of develop/colaborates from eGW to IRM too.
Translation for more than twenty languages.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
They seem to share similiar "modularity". However, the
changes required to fit an existing, standalone product into
one or more of them could vary greatly.
Maybe we divide them up, determine the directions IRM would
need to go for each, and discuss it to see if they might be
a universal solutions? Of course, it can be difficult the
please everyone all the time...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
To summarise: you want IRM to effectively become a module or
plugin (or whatever you want to call it) for one (or more)
of eGroupWare, phpGroupWare, or perhaps some other system.
My reasons for not liking this idea include:
* Integrated apps are fine, until you need to do something
that the environment doesn't allow, or something. Then you
get to wrestle *against* the system, rather than letting it
help you. I've written Access apps, so I know of what I speak.
* phpGroupWare, in particular, I have experience with. It
has an abysmal track record with regard to security, and
when I last played with it (albeit quite a while ago now)
the API wasn't something I was willing to work with. It may
have gotten a lot better recently (ghods I hope so), but
past history doesn't endear me to it.
* If we select any one environment to tie IRM to, then we
effectively snub anyone who is an impassioned advocate of a
different system. So far we've seen 4 possible suggestions
for systems to integrate with. A naive assessment of that
indicates that, by tying ourselves to any one of those
systems, we've probably reduced our likely userbase by 3/4.
I don't like that sort of math. I see this problem a lot
with Zope apps -- once you start down the Zope path, forever
will it dominate your destiny. You may as well just start
writing VB apps and be done with it...
All that being said, I'm not particularly adverse to the
general concept of tying things together to provide a
consistent look-n-feel -- I can see the advantages to it in
many situations. If someone wants to provide some input in
what would be required to integrate IRM into any one of
these environments (or any other system they might prefer),
I'm happy to discuss and integrate work people are willing
to do, *as* *long* *as* it doesn't terminally interfere with
IRM's operation as a standalone system. On-going work to
clean up the code, and make it more modular and
"templatable" should help a lot to make it easier to tie IRM
into larger systems.
For major discussions on this general topic, I'd ask that
you raise the issue on irm-devel, where we can have a proper
flame-war*ahem*discussion on the subject. (grin)
Particularly, the larger implementation issues (how each
environment can be tied into) will probably take some time
to hash out.
- Matt
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anyone who is interested in seeing groupware integration
proceed really does need to get the ball rolling. See my
previous comments for how I think that can be done.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well seeing as no one is steping forward to make any change
for this in IRM and there has been no updates to the thread
for 6 months i would say this is a dead duck.
If anyone feels really strongly about it please start hacking
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Logged In: YES
user_id=621643
I'm afraid you're going to have to be a bit more specific --
which portions of IRM do you think should be integrated with
eGroupWare? Users and passwords? Does eGroupWare have a
ticketing module, or some internal way of associating users
with computers? Having never used it, I don't know what
it's capable of, nor do I have any experience programming
to/for it.
Also, do you have any references (links to the eGroupWare
site, for instance) which document how eGW does what you
want done, so it's easier for us to develop against it?
Logged In: YES
user_id=933511
eGW has trouble ticket system the same of IRM, but not have anything
for control / stock machines. eGW is good for comunities and companies
it has a lot of modules with same user/password and same url. You have
on it trouble ticket, wiki, diary, ... and why not a Information Resource ?
You can see all about eGW on egroupware.org
Benefits for IRM:
Thousands of develop/colaborates from eGW to IRM too.
Translation for more than twenty languages.
Logged In: YES
user_id=658589
It make sense also to me.
eGW (but also phpGrouWare) is a ``groupware'' environment,
that have some ``apps'' within: the basic ones are calendar,
email, addressbook, ...
The good for irm are that, integrating it in *GW, could
achive, gratis, things like:
+ db independence
+ css/themes and a powerful api
+ user handling and authentication
+ knowledgebase
Pratically irm could focus only on their goal, so computer
inventory and tts.
*GW have an inventory module and a tts system, but i think
too generic for traking computers.
As a side note, and only for my like, i prefer phpGroupWare. ;)
Logged In: YES
user_id=255860
OK, I'll play devil's advocate. :-)
I like Tiki http://tikiwiki.org - others out there might
like Xoops.
They seem to share similiar "modularity". However, the
changes required to fit an existing, standalone product into
one or more of them could vary greatly.
Maybe we divide them up, determine the directions IRM would
need to go for each, and discuss it to see if they might be
a universal solutions? Of course, it can be difficult the
please everyone all the time...
Logged In: YES
user_id=621643
To summarise: you want IRM to effectively become a module or
plugin (or whatever you want to call it) for one (or more)
of eGroupWare, phpGroupWare, or perhaps some other system.
My reasons for not liking this idea include:
* Integrated apps are fine, until you need to do something
that the environment doesn't allow, or something. Then you
get to wrestle *against* the system, rather than letting it
help you. I've written Access apps, so I know of what I speak.
* phpGroupWare, in particular, I have experience with. It
has an abysmal track record with regard to security, and
when I last played with it (albeit quite a while ago now)
the API wasn't something I was willing to work with. It may
have gotten a lot better recently (ghods I hope so), but
past history doesn't endear me to it.
* If we select any one environment to tie IRM to, then we
effectively snub anyone who is an impassioned advocate of a
different system. So far we've seen 4 possible suggestions
for systems to integrate with. A naive assessment of that
indicates that, by tying ourselves to any one of those
systems, we've probably reduced our likely userbase by 3/4.
I don't like that sort of math. I see this problem a lot
with Zope apps -- once you start down the Zope path, forever
will it dominate your destiny. You may as well just start
writing VB apps and be done with it...
All that being said, I'm not particularly adverse to the
general concept of tying things together to provide a
consistent look-n-feel -- I can see the advantages to it in
many situations. If someone wants to provide some input in
what would be required to integrate IRM into any one of
these environments (or any other system they might prefer),
I'm happy to discuss and integrate work people are willing
to do, *as* *long* *as* it doesn't terminally interfere with
IRM's operation as a standalone system. On-going work to
clean up the code, and make it more modular and
"templatable" should help a lot to make it easier to tie IRM
into larger systems.
For major discussions on this general topic, I'd ask that
you raise the issue on irm-devel, where we can have a proper
flame-war*ahem*discussion on the subject. (grin)
Particularly, the larger implementation issues (how each
environment can be tied into) will probably take some time
to hash out.
- Matt
Logged In: YES
user_id=621643
Anyone who is interested in seeing groupware integration
proceed really does need to get the ball rolling. See my
previous comments for how I think that can be done.
Logged In: YES
user_id=255024
Well seeing as no one is steping forward to make any change
for this in IRM and there has been no updates to the thread
for 6 months i would say this is a dead duck.
If anyone feels really strongly about it please start hacking