enlightenment-devel

Hello,
Ok, haven't got a lot of responses (not that I gave it a huge amount of
time, I'm inpatent) but, a follow on email to what we want out of the site.
How do we get it.
Lets us assume, for now, XSM is our CMS of choice. It will handle the
static pages for all 'normal pages'. It will handle the news page
(which, will hopefully be able to be displayed on both the home page for
2-3 articles and in the news page, Handy?). The FAQ will be XSM. If we
want to hook up for the user to download the faq to their system we can
grab the .xml file XSM generates and post process if needed (Handy, can
we hook post processing scripts in so after a page is written out, fire
script?) and stick this into specific spots in the webserver.
The main docs pages will be in XSM. The API docs will be generated from
CVS, with links from XSM. The other docs that are in CVS will also be
autogen'd on commit with links from XSM.
That make sense as a starting point?
So, what does that leave us with to sort out.
1- User forums. The easiest is to grab something previously created and
use that. There are two issues.
a) do we want to migrate data from edevelop, if so, how.
b) user authentication. We want this to have the same authentication
as XSM.
So, we'll either need to modify this in the forum software, or do
some fancy footwork.
(XSM writes its user db and we parse that into the forum db, or
into LDAP or something?)
2- Wiki. Do we want a user wiki? Something for users to put their info
on, put up a page for
their efl apps, or their theme they're working on. If we want this,
again, how do we integrate
the user database with XSM. Probably a similar issue as 1. Which
Wiki software do we use?
Mediawiki?
3- Bug database. Basically same as above. How to integrate users, which
bug software to
use. We currently use Mantis. Do we stick with that? (Losing the
current bug data is
unacceptable so if we go to something else we _have_ to migrate.)
4- Release directory list. It sounds like we can hook php into XSM. This
page will then just
be controlled by XSM. (Assuming I'm correct on the XSM php front.)
I just thought of another feature we may want on the site. Autobuild
information. Every 10 min or something rebuild everything, put up page
with build errors, build warnings, etc. Possibly just a php script in
XSM or tinderbox?
Now. I _know_ everyone has their favorite bug database, favorite wiki
software. Favorite hand to use while touching themselves. Thats fine. I
want to here what you like. I only want to hear it _once_. I _don't_
want to hear you bitch about what someone else likes.
Right now, we need ideas on what to use and how we can hook the pieces
together. We don't want a giant mis-mash site. We also don't want to
write all this shit ourselves. How can we get this stuff to fit together
in terms of UI and in terms of user database and administration?
(And just as a disclaimer. I've been avoiding XSM like the plague due to
some early issues. I still think that we should use XSM as a _starting_
point. Once we've tried it on the new site with the other components
then we can decided if it holds wind. To which, I've started poking XSM
again.)
dan

On Tue, 12 Sep 2006 21:38:27 -0400 dan sinclair <zero@...>
wrote:
> The FAQ will be XSM. If we want to hook up for the user to download
> the faq to their system we can grab the .xml file XSM generates and
> post process if needed=20
We have two XML parsers in CVS, maybe we can make use of one of them?
I don't know much about exml, but I wrote xmlame, and it is just a
really basic parser that is good enough for FDO menu files. It might
be good enough for the XSM .xml files.
> 1- User forums. The easiest is to grab something previously created
> and use that. There are two issues.
> a) do we want to migrate data from edevelop, if so, how.
If we do migrate, the easiest thing we can do is to use the same forum
software.
> I just thought of another feature we may want on the site. Autobuild=20
> information. Every 10 min or something rebuild everything, put up
> page with build errors, build warnings, etc. Possibly just a php
> script in XSM or tinderbox?
I do rebuild almost everything in cvs on a regular basis. Starting
from make clean distclean through to final install takes almost an hour
on an Athlon 3000+ with fast hard drives and plenty of ram.

On 12-Sep-06, at 11:37 PM, David Seikel wrote:
> On Tue, 12 Sep 2006 21:38:27 -0400 dan sinclair <zero@...>
> wrote:
>
>> The FAQ will be XSM. If we want to hook up for the user to download
>> the faq to their system we can grab the .xml file XSM generates and
>> post process if needed
>
> We have two XML parsers in CVS, maybe we can make use of one of them?
> I don't know much about exml, but I wrote xmlame, and it is just a
> really basic parser that is good enough for FDO menu files. It might
> be good enough for the XSM .xml files.
I don't think there is any reason for this to be done in C. It would
be better handled by a simple scripting language I'd think. But, the
implementation is unimportant at this point.
>
>> 1- User forums. The easiest is to grab something previously created
>> and use that. There are two issues.
>> a) do we want to migrate data from edevelop, if so, how.
>
> If we do migrate, the easiest thing we can do is to use the same forum
> software.
>
Unless there is a really good reason to switch. Blake, comments on
the current forum software?
>> I just thought of another feature we may want on the site. Autobuild
>> information. Every 10 min or something rebuild everything, put up
>> page with build errors, build warnings, etc. Possibly just a php
>> script in XSM or tinderbox?
>
> I do rebuild almost everything in cvs on a regular basis. Starting
> from make clean distclean through to final install takes almost an
> hour
> on an Athlon 3000+ with fast hard drives and plenty of ram.
We'll have to work out the logistics, but possibly not doing make
clean before hand will speed things up as we just rebuild whats
changed. Else, we rebuild every 2 hrs or something.
dan

dan sinclair wrote:
> On 12-Sep-06, at 11:37 PM, David Seikel wrote:
>
>> On Tue, 12 Sep 2006 21:38:27 -0400 dan sinclair <zero@...>
<snip>
>>> 1- User forums. The easiest is to grab something previously created
>>> and use that. There are two issues.
>>> a) do we want to migrate data from edevelop, if so, how.
>> If we do migrate, the easiest thing we can do is to use the same forum
>> software.
>>
>
> Unless there is a really good reason to switch. Blake, comments on
> the current forum software?
>
Personally, I hate maintaining it.
1. It requires a full Drupal installation. (How many CMSes do you
desire? :))
2. Unless you require logins for all replies (which is fine.. currently
edevelop.org allows anonymous posts.) then you have major spam issues.
3. The theme was also custom made for it, so changes to it will require
some hacking.
4. Drupal being a fairly popular CMS there are a pretty constant stream
of updates for security holes.
5. To get a decent installation of Drupal you have to install a LOT of
modules, which don't always work smoothly with updates. (May not be an
issue for e.org)
6. I have not updated to Drupal 4.7.x because of the customized nature
of the forums.
Aside from that, the forums need a lot of cleanup. It might be best to
start fresh with something else. (no, I will not recommend anything. :P)
-Blake

dan sinclair wrote:
> Hello,
>
> Ok, haven't got a lot of responses (not that I gave it a huge amount of
> time, I'm inpatent) but, a follow on email to what we want out of the site.
>
> How do we get it.
>
> Lets us assume, for now, XSM is our CMS of choice. It will handle the
> static pages for all 'normal pages'. It will handle the news page
> (which, will hopefully be able to be displayed on both the home page for
> 2-3 articles and in the news page, Handy?).
sure thing. Any "list based" page can be summarised using simple markup
which can be inserted into something like the front page using the
template system.
> The FAQ will be XSM. If we
> want to hook up for the user to download the faq to their system we can
> grab the .xml file XSM generates and post process if needed (Handy, can
> we hook post processing scripts in so after a page is written out, fire
> script?) and stick this into specific spots in the webserver.
>
post processing is not currently available as a hook, but you can look
at mtime values on files. perhaps RSS might be useful here?
> The main docs pages will be in XSM. The API docs will be generated from
> CVS, with links from XSM. The other docs that are in CVS will also be
> autogen'd on commit with links from XSM.
>
> That make sense as a starting point?
>
>
yup :)
> So, what does that leave us with to sort out.
>
> 1- User forums. The easiest is to grab something previously created and
> use that. There are two issues.
> a) do we want to migrate data from edevelop, if so, how.
> b) user authentication. We want this to have the same authentication
> as XSM.
> So, we'll either need to modify this in the forum software, or do
> some fancy footwork.
> (XSM writes its user db and we parse that into the forum db, or
> into LDAP or something?)
>
>
XSM does want to use LDAP, perhaps this would be the push it needs :)
> 2- Wiki. Do we want a user wiki? Something for users to put their info
> on, put up a page for
> their efl apps, or their theme they're working on. If we want this,
> again, how do we integrate
> the user database with XSM. Probably a similar issue as 1. Which
> Wiki software do we use?
> Mediawiki?
>
> 3- Bug database. Basically same as above. How to integrate users, which
> bug software to
> use. We currently use Mantis. Do we stick with that? (Losing the
> current bug data is
> unacceptable so if we go to something else we _have_ to migrate.)
>
>
I personally like mantis, though I have grown to love Trac ;)
> 4- Release directory list. It sounds like we can hook php into XSM. This
> page will then just
> be controlled by XSM. (Assuming I'm correct on the XSM php front.)
>
>
Yeah, sure thing - if you want the file list generated on the file
system. There is a "files" doctype in XSM which allows you to upload
files for download (if you see what I mean) and you can categorise the
page. So both options are viable.
> I just thought of another feature we may want on the site. Autobuild
> information. Every 10 min or something rebuild everything, put up page
> with build errors, build warnings, etc. Possibly just a php script in
> XSM or tinderbox?
>
>
XSM could run scripts to present this, but currently it has no
scheduler, so it could not (yet) be used to fire off the rebuild event.
> Now. I _know_ everyone has their favorite bug database, favorite wiki
> software. Favorite hand to use while touching themselves. Thats fine. I
> want to here what you like. I only want to hear it _once_. I _don't_
> want to hear you bitch about what someone else likes.
>
> Right now, we need ideas on what to use and how we can hook the pieces
> together. We don't want a giant mis-mash site. We also don't want to
> write all this shit ourselves. How can we get this stuff to fit together
> in terms of UI and in terms of user database and administration?
>
> (And just as a disclaimer. I've been avoiding XSM like the plague due to
> some early issues. I still think that we should use XSM as a _starting_
> point. Once we've tried it on the new site with the other components
> then we can decided if it holds wind. To which, I've started poking XSM
> again.)
>
And you have come up with some constructive comments which will be put
in ASAP. Of course, registering these issues on
http://dev.rectang.com/projects/xsm (click "new issue") will get a more
"reliable" response ;)
> dan
>
>
Andy

Andrew Williams wrote:
> dan sinclair wrote:
>> Hello,
>>
>> Ok, haven't got a lot of responses (not that I gave it a huge amount
>> of time, I'm inpatent) but, a follow on email to what we want out of
>> the site.
>>
>> How do we get it.
>>
>> Lets us assume, for now, XSM is our CMS of choice. It will handle the
>> static pages for all 'normal pages'. It will handle the news page
>> (which, will hopefully be able to be displayed on both the home page
>> for 2-3 articles and in the news page, Handy?).
> sure thing. Any "list based" page can be summarised using simple markup
> which can be inserted into something like the front page using the
> template system.
>> The FAQ will be XSM. If we want to hook up for the user to download
>> the faq to their system we can grab the .xml file XSM generates and
>> post process if needed (Handy, can we hook post processing scripts in
>> so after a page is written out, fire script?) and stick this into
>> specific spots in the webserver.
>>
> post processing is not currently available as a hook, but you can look
> at mtime values on files. perhaps RSS might be useful here?
>> The main docs pages will be in XSM. The API docs will be generated
>> from CVS, with links from XSM. The other docs that are in CVS will
>> also be autogen'd on commit with links from XSM.
>>
>> That make sense as a starting point?
>>
>>
Just thought of two more possible things for the site.
1- cvsweb. I know we have this running on Kevin's site now. So we can
either bring it in house, or just make cvsweb.enlightenment.org point to
his site. Kevin, opinions?
2- mailing list archives. Do we want the hassle of hosting these? sf
seems to be doing an OK job of it (not that I look much).
dan

On Wed, 13 Sep 2006 10:32:00 +0100 Andrew Williams <andy@...>
babbled:
OK - I have been waiting for the dust to settle (too much email to handle!) :)
I will summarise what I think the WEBSITE needs (regular builds with errors are
orthogonal to the WEBSITE - they can output web pages to be linked to
though...).
The list of what we have and what handles it currently, do they need user auth.
1. news posting - summaries on front page (XSM, auth)
2. content creation and editing (XSM, auth)
3. forums (drupal, auth)
4. bug db/reporting (mantis - i think, auth)
5. on-disk file repo for download (custom PHP)
6. documentation (XSM, auth)
7. webcvs (kevb/webcvs)
8. user uploads of themes etc. (XSM - done by hand, auth)
we, as dan pointed out, need to unify authentication/user info - we can't go
and have all the systems separate. they need to be unified - 1 login. frankly -
i think we need to either look at making XSM do all of the above, or we need to
canvas for a solution that does all of the above for us already. we do not need
to go write our own cms/wiki/whatever we are not in the business of building
"websites". we are in the business of writing "code". the website is a means to
an end.
xsm has served well - and i am happy to keep using it - if we can accomodate
what we need easily. the bits not needing auth can be put in with XSM - those
not using XSM and needing auth are the problem.
so - we
1. bring xsm up to speed and merge everything in and do all that work
2. we look for an alternative (if one exists)
3. we write our own (oh bloody hell i hope not!)
4. we keep depating this until we all get bored and find something better to do.
so our 2 real possibilities are 1 & 2.
so - let's look at this in parallel. what are our chances of 1. and gettign xsm
to manage things so we can have forums, bug tracker, etc. etc. cleanly (and our
list of issues with xsm)
and what are our alternatives - wiki's with bug trackers (trac?)? trac is very
limiting in the page content land - if u want simple things its fine, but
otherwise is lacking. twiki i understand is better BUT not sure about adding
bug trackers etc. drupal is a monster. what about forums combined with these?...
> dan sinclair wrote:
> > Hello,
> >
> > Ok, haven't got a lot of responses (not that I gave it a huge amount of
> > time, I'm inpatent) but, a follow on email to what we want out of the site.
> >
> > How do we get it.
> >
> > Lets us assume, for now, XSM is our CMS of choice. It will handle the
> > static pages for all 'normal pages'. It will handle the news page
> > (which, will hopefully be able to be displayed on both the home page for
> > 2-3 articles and in the news page, Handy?).
> sure thing. Any "list based" page can be summarised using simple markup
> which can be inserted into something like the front page using the
> template system.
> > The FAQ will be XSM. If we
> > want to hook up for the user to download the faq to their system we can
> > grab the .xml file XSM generates and post process if needed (Handy, can
> > we hook post processing scripts in so after a page is written out, fire
> > script?) and stick this into specific spots in the webserver.
> >
> post processing is not currently available as a hook, but you can look
> at mtime values on files. perhaps RSS might be useful here?
> > The main docs pages will be in XSM. The API docs will be generated from
> > CVS, with links from XSM. The other docs that are in CVS will also be
> > autogen'd on commit with links from XSM.
> >
> > That make sense as a starting point?
> >
> >
> yup :)
> > So, what does that leave us with to sort out.
> >
> > 1- User forums. The easiest is to grab something previously created and
> > use that. There are two issues.
> > a) do we want to migrate data from edevelop, if so, how.
> > b) user authentication. We want this to have the same authentication
> > as XSM.
> > So, we'll either need to modify this in the forum software, or do
> > some fancy footwork.
> > (XSM writes its user db and we parse that into the forum db, or
> > into LDAP or something?)
> >
> >
> XSM does want to use LDAP, perhaps this would be the push it needs :)
> > 2- Wiki. Do we want a user wiki? Something for users to put their info
> > on, put up a page for
> > their efl apps, or their theme they're working on. If we want this,
> > again, how do we integrate
> > the user database with XSM. Probably a similar issue as 1. Which
> > Wiki software do we use?
> > Mediawiki?
> >
> > 3- Bug database. Basically same as above. How to integrate users, which
> > bug software to
> > use. We currently use Mantis. Do we stick with that? (Losing the
> > current bug data is
> > unacceptable so if we go to something else we _have_ to migrate.)
> >
> >
> I personally like mantis, though I have grown to love Trac ;)
> > 4- Release directory list. It sounds like we can hook php into XSM. This
> > page will then just
> > be controlled by XSM. (Assuming I'm correct on the XSM php front.)
> >
> >
> Yeah, sure thing - if you want the file list generated on the file
> system. There is a "files" doctype in XSM which allows you to upload
> files for download (if you see what I mean) and you can categorise the
> page. So both options are viable.
> > I just thought of another feature we may want on the site. Autobuild
> > information. Every 10 min or something rebuild everything, put up page
> > with build errors, build warnings, etc. Possibly just a php script in
> > XSM or tinderbox?
> >
> >
> XSM could run scripts to present this, but currently it has no
> scheduler, so it could not (yet) be used to fire off the rebuild event.
> > Now. I _know_ everyone has their favorite bug database, favorite wiki
> > software. Favorite hand to use while touching themselves. Thats fine. I
> > want to here what you like. I only want to hear it _once_. I _don't_
> > want to hear you bitch about what someone else likes.
> >
> > Right now, we need ideas on what to use and how we can hook the pieces
> > together. We don't want a giant mis-mash site. We also don't want to
> > write all this shit ourselves. How can we get this stuff to fit together
> > in terms of UI and in terms of user database and administration?
> >
> > (And just as a disclaimer. I've been avoiding XSM like the plague due to
> > some early issues. I still think that we should use XSM as a _starting_
> > point. Once we've tried it on the new site with the other components
> > then we can decided if it holds wind. To which, I've started poking XSM
> > again.)
> >
> And you have come up with some constructive comments which will be put
> in ASAP. Of course, registering these issues on
> http://dev.rectang.com/projects/xsm (click "new issue") will get a more
> "reliable" response ;)
> > dan
> >
> >
> Andy
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> enlightenment-devel mailing list
> enlightenment-devel@...
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
--
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) raster@...
裸好多
Tokyo, Japan (東京 日本)

I would recommend against Drupal for forums, they don't look good, they lac=
k=20
basic functionality in many browsers, the search function doesn't work very=
=20
well, and yet remain complex to maintain.
My recomendation would be RForum (http://rforum.andreas-s.net/rforum).
That merges the froum with the mailing list in http://www.ruby-forum.com/.
Or I could help to customize a Simple Machines Forum, to make the interface=
s=20
less cluttered with crap, perhaps even include a mailing list module.
El S=E1bado 16 Septiembre 2006 01:20, Carsten Haitzler escribi=F3:
> On Wed, 13 Sep 2006 10:32:00 +0100 Andrew Williams <andy@...>
> babbled:
>
> OK - I have been waiting for the dust to settle (too much email to handle=
!)
> :)
>
> I will summarise what I think the WEBSITE needs (regular builds with erro=
rs
> are orthogonal to the WEBSITE - they can output web pages to be linked to
> though...).
>
> The list of what we have and what handles it currently, do they need user
> auth.
>
> 1. news posting - summaries on front page (XSM, auth)
> 2. content creation and editing (XSM, auth)
> 3. forums (drupal, auth)
> 4. bug db/reporting (mantis - i think, auth)
> 5. on-disk file repo for download (custom PHP)
> 6. documentation (XSM, auth)
> 7. webcvs (kevb/webcvs)
> 8. user uploads of themes etc. (XSM - done by hand, auth)
>
> we, as dan pointed out, need to unify authentication/user info - we can't
> go and have all the systems separate. they need to be unified - 1 login.
> frankly - i think we need to either look at making XSM do all of the abov=
e,
> or we need to canvas for a solution that does all of the above for us
> already. we do not need to go write our own cms/wiki/whatever we are not =
in
> the business of building "websites". we are in the business of writing
> "code". the website is a means to an end.
>
> xsm has served well - and i am happy to keep using it - if we can
> accomodate what we need easily. the bits not needing auth can be put in
> with XSM - those not using XSM and needing auth are the problem.
>
> so - we
> 1. bring xsm up to speed and merge everything in and do all that work
> 2. we look for an alternative (if one exists)
> 3. we write our own (oh bloody hell i hope not!)
> 4. we keep depating this until we all get bored and find something better
> to do.
>
> so our 2 real possibilities are 1 & 2.
>
> so - let's look at this in parallel. what are our chances of 1. and getti=
gn
> xsm to manage things so we can have forums, bug tracker, etc. etc. cleanly
> (and our list of issues with xsm)
>
> and what are our alternatives - wiki's with bug trackers (trac?)? trac is
> very limiting in the page content land - if u want simple things its fine,
> but otherwise is lacking. twiki i understand is better BUT not sure about
> adding bug trackers etc. drupal is a monster. what about forums combined
> with these?...
>
> > dan sinclair wrote:
> > > Hello,
> > >
> > > Ok, haven't got a lot of responses (not that I gave it a huge amount =
of
> > > time, I'm inpatent) but, a follow on email to what we want out of the
> > > site.
> > >
> > > How do we get it.
> > >
> > > Lets us assume, for now, XSM is our CMS of choice. It will handle the
> > > static pages for all 'normal pages'. It will handle the news page
> > > (which, will hopefully be able to be displayed on both the home page
> > > for 2-3 articles and in the news page, Handy?).
> >
> > sure thing. Any "list based" page can be summarised using simple markup
> > which can be inserted into something like the front page using the
> > template system.
> >
> > > The FAQ will be XSM. If we
> > > want to hook up for the user to download the faq to their system we c=
an
> > > grab the .xml file XSM generates and post process if needed (Handy, c=
an
> > > we hook post processing scripts in so after a page is written out, fi=
re
> > > script?) and stick this into specific spots in the webserver.
> >
> > post processing is not currently available as a hook, but you can look
> > at mtime values on files. perhaps RSS might be useful here?
> >
> > > The main docs pages will be in XSM. The API docs will be generated fr=
om
> > > CVS, with links from XSM. The other docs that are in CVS will also be
> > > autogen'd on commit with links from XSM.
> > >
> > > That make sense as a starting point?
> >
> > yup :)
> >
> > > So, what does that leave us with to sort out.
> > >
> > > 1- User forums. The easiest is to grab something previously created a=
nd
> > > use that. There are two issues.
> > > a) do we want to migrate data from edevelop, if so, how.
> > > b) user authentication. We want this to have the same authenticati=
on
> > > as XSM.
> > > So, we'll either need to modify this in the forum software, or =
do
> > > some fancy footwork.
> > > (XSM writes its user db and we parse that into the forum db, or
> > > into LDAP or something?)
> >
> > XSM does want to use LDAP, perhaps this would be the push it needs :)
> >
> > > 2- Wiki. Do we want a user wiki? Something for users to put their info
> > > on, put up a page for
> > > their efl apps, or their theme they're working on. If we want thi=
s,
> > > again, how do we integrate
> > > the user database with XSM. Probably a similar issue as 1. Which
> > > Wiki software do we use?
> > > Mediawiki?
> > >
> > > 3- Bug database. Basically same as above. How to integrate users, whi=
ch
> > > bug software to
> > > use. We currently use Mantis. Do we stick with that? (Losing the
> > > current bug data is
> > > unacceptable so if we go to something else we _have_ to migrate.)
> >
> > I personally like mantis, though I have grown to love Trac ;)
> >
> > > 4- Release directory list. It sounds like we can hook php into XSM.
> > > This page will then just
> > > be controlled by XSM. (Assuming I'm correct on the XSM php front.)
> >
> > Yeah, sure thing - if you want the file list generated on the file
> > system. There is a "files" doctype in XSM which allows you to upload
> > files for download (if you see what I mean) and you can categorise the
> > page. So both options are viable.
> >
> > > I just thought of another feature we may want on the site. Autobuild
> > > information. Every 10 min or something rebuild everything, put up page
> > > with build errors, build warnings, etc. Possibly just a php script in
> > > XSM or tinderbox?
> >
> > XSM could run scripts to present this, but currently it has no
> > scheduler, so it could not (yet) be used to fire off the rebuild event.
> >
> > > Now. I _know_ everyone has their favorite bug database, favorite wiki
> > > software. Favorite hand to use while touching themselves. Thats fine.=
I
> > > want to here what you like. I only want to hear it _once_. I _don't_
> > > want to hear you bitch about what someone else likes.
> > >
> > > Right now, we need ideas on what to use and how we can hook the pieces
> > > together. We don't want a giant mis-mash site. We also don't want to
> > > write all this shit ourselves. How can we get this stuff to fit
> > > together in terms of UI and in terms of user database and
> > > administration?
> > >
> > > (And just as a disclaimer. I've been avoiding XSM like the plague due
> > > to some early issues. I still think that we should use XSM as a
> > > _starting_ point. Once we've tried it on the new site with the other
> > > components then we can decided if it holds wind. To which, I've start=
ed
> > > poking XSM again.)
> >
> > And you have come up with some constructive comments which will be put
> > in ASAP. Of course, registering these issues on
> > http://dev.rectang.com/projects/xsm (click "new issue") will get a more
> > "reliable" response ;)
> >
> > > dan
> >
> > Andy
> >
> > -----------------------------------------------------------------------=
=2D-
> > Using Tomcat but need to do more? Need to support web services, securit=
y?
> > Get stuff done quickly with pre-integrated technology to make your job
> > easier Download IBM WebSphere Application Server v.1.0.1 based on Apache
> > Geronimo
> > http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat=
=3D121642
> > _______________________________________________
> > enlightenment-devel mailing list
> > enlightenment-devel@...
> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

On Sat, 16 Sep 2006 14:20:59 -0300 Andres Blanc <andresblanc@...> b=
abbled:
and what about the rest of it? so we have yet another independent piece o=
f
code/site that doesn't work with the rest :( we need to at least scout fo=
r
something that offers all of what we need - OR we modify what we have to =
fit.
we can't go "use X for forums, Y for bugtracker, Z for docs" as an altern=
ative
- because that is exactly where we are now and doing so will not improve
anything. if that's the best we have then we had better work with what we
have. :(
> I would recommend against Drupal for forums, they don't look good, they=
lack=20
> basic functionality in many browsers, the search function doesn't work =
very=20
> well, and yet remain complex to maintain.
>=20
> My recomendation would be RForum (http://rforum.andreas-s.net/rforum).
> That merges the froum with the mailing list in http://www.ruby-forum.co=
m/.
>=20
> Or I could help to customize a Simple Machines Forum, to make the inter=
faces=20
> less cluttered with crap, perhaps even include a mailing list module.
>=20
> El S=C3=A1bado 16 Septiembre 2006 01:20, Carsten Haitzler escribi=C3=B3=
:
> > On Wed, 13 Sep 2006 10:32:00 +0100 Andrew Williams <andy@...=
.uk>
> > babbled:
> >
> > OK - I have been waiting for the dust to settle (too much email to ha=
ndle!)
> > :)
> >
> > I will summarise what I think the WEBSITE needs (regular builds with =
errors
> > are orthogonal to the WEBSITE - they can output web pages to be linke=
d to
> > though...).
> >
> > The list of what we have and what handles it currently, do they need =
user
> > auth.
> >
> > 1. news posting - summaries on front page (XSM, auth)
> > 2. content creation and editing (XSM, auth)
> > 3. forums (drupal, auth)
> > 4. bug db/reporting (mantis - i think, auth)
> > 5. on-disk file repo for download (custom PHP)
> > 6. documentation (XSM, auth)
> > 7. webcvs (kevb/webcvs)
> > 8. user uploads of themes etc. (XSM - done by hand, auth)
> >
> > we, as dan pointed out, need to unify authentication/user info - we c=
an't
> > go and have all the systems separate. they need to be unified - 1 log=
in.
> > frankly - i think we need to either look at making XSM do all of the =
above,
> > or we need to canvas for a solution that does all of the above for us
> > already. we do not need to go write our own cms/wiki/whatever we are =
not in
> > the business of building "websites". we are in the business of writin=
g
> > "code". the website is a means to an end.
> >
> > xsm has served well - and i am happy to keep using it - if we can
> > accomodate what we need easily. the bits not needing auth can be put =
in
> > with XSM - those not using XSM and needing auth are the problem.
> >
> > so - we
> > 1. bring xsm up to speed and merge everything in and do all that work
> > 2. we look for an alternative (if one exists)
> > 3. we write our own (oh bloody hell i hope not!)
> > 4. we keep depating this until we all get bored and find something be=
tter
> > to do.
> >
> > so our 2 real possibilities are 1 & 2.
> >
> > so - let's look at this in parallel. what are our chances of 1. and g=
ettign
> > xsm to manage things so we can have forums, bug tracker, etc. etc. cl=
eanly
> > (and our list of issues with xsm)
> >
> > and what are our alternatives - wiki's with bug trackers (trac?)? tra=
c is
> > very limiting in the page content land - if u want simple things its =
fine,
> > but otherwise is lacking. twiki i understand is better BUT not sure a=
bout
> > adding bug trackers etc. drupal is a monster. what about forums combi=
ned
> > with these?...
> >
> > > dan sinclair wrote:
> > > > Hello,
> > > >
> > > > Ok, haven't got a lot of responses (not that I gave it a huge amo=
unt of
> > > > time, I'm inpatent) but, a follow on email to what we want out of=
the
> > > > site.
> > > >
> > > > How do we get it.
> > > >
> > > > Lets us assume, for now, XSM is our CMS of choice. It will handle=
the
> > > > static pages for all 'normal pages'. It will handle the news page
> > > > (which, will hopefully be able to be displayed on both the home p=
age
> > > > for 2-3 articles and in the news page, Handy?).
> > >
> > > sure thing. Any "list based" page can be summarised using simple ma=
rkup
> > > which can be inserted into something like the front page using the
> > > template system.
> > >
> > > > The FAQ will be XSM. If we
> > > > want to hook up for the user to download the faq to their system =
we can
> > > > grab the .xml file XSM generates and post process if needed (Hand=
y, can
> > > > we hook post processing scripts in so after a page is written out=
, fire
> > > > script?) and stick this into specific spots in the webserver.
> > >
> > > post processing is not currently available as a hook, but you can l=
ook
> > > at mtime values on files. perhaps RSS might be useful here?
> > >
> > > > The main docs pages will be in XSM. The API docs will be generate=
d from
> > > > CVS, with links from XSM. The other docs that are in CVS will als=
o be
> > > > autogen'd on commit with links from XSM.
> > > >
> > > > That make sense as a starting point?
> > >
> > > yup :)
> > >
> > > > So, what does that leave us with to sort out.
> > > >
> > > > 1- User forums. The easiest is to grab something previously creat=
ed and
> > > > use that. There are two issues.
> > > > a) do we want to migrate data from edevelop, if so, how.
> > > > b) user authentication. We want this to have the same authenti=
cation
> > > > as XSM.
> > > > So, we'll either need to modify this in the forum software,=
or do
> > > > some fancy footwork.
> > > > (XSM writes its user db and we parse that into the forum db=
, or
> > > > into LDAP or something?)
> > >
> > > XSM does want to use LDAP, perhaps this would be the push it needs =
:)
> > >
> > > > 2- Wiki. Do we want a user wiki? Something for users to put their=
info
> > > > on, put up a page for
> > > > their efl apps, or their theme they're working on. If we want=
this,
> > > > again, how do we integrate
> > > > the user database with XSM. Probably a similar issue as 1. W=
hich
> > > > Wiki software do we use?
> > > > Mediawiki?
> > > >
> > > > 3- Bug database. Basically same as above. How to integrate users,=
which
> > > > bug software to
> > > > use. We currently use Mantis. Do we stick with that? (Losing =
the
> > > > current bug data is
> > > > unacceptable so if we go to something else we _have_ to migra=
te.)
> > >
> > > I personally like mantis, though I have grown to love Trac ;)
> > >
> > > > 4- Release directory list. It sounds like we can hook php into XS=
M.
> > > > This page will then just
> > > > be controlled by XSM. (Assuming I'm correct on the XSM php fr=
ont.)
> > >
> > > Yeah, sure thing - if you want the file list generated on the file
> > > system. There is a "files" doctype in XSM which allows you to uploa=
d
> > > files for download (if you see what I mean) and you can categorise =
the
> > > page. So both options are viable.
> > >
> > > > I just thought of another feature we may want on the site. Autobu=
ild
> > > > information. Every 10 min or something rebuild everything, put up=
page
> > > > with build errors, build warnings, etc. Possibly just a php scrip=
t in
> > > > XSM or tinderbox?
> > >
> > > XSM could run scripts to present this, but currently it has no
> > > scheduler, so it could not (yet) be used to fire off the rebuild ev=
ent.
> > >
> > > > Now. I _know_ everyone has their favorite bug database, favorite =
wiki
> > > > software. Favorite hand to use while touching themselves. Thats f=
ine. I
> > > > want to here what you like. I only want to hear it _once_. I _don=
't_
> > > > want to hear you bitch about what someone else likes.
> > > >
> > > > Right now, we need ideas on what to use and how we can hook the p=
ieces
> > > > together. We don't want a giant mis-mash site. We also don't want=
to
> > > > write all this shit ourselves. How can we get this stuff to fit
> > > > together in terms of UI and in terms of user database and
> > > > administration?
> > > >
> > > > (And just as a disclaimer. I've been avoiding XSM like the plague=
due
> > > > to some early issues. I still think that we should use XSM as a
> > > > _starting_ point. Once we've tried it on the new site with the ot=
her
> > > > components then we can decided if it holds wind. To which, I've s=
tarted
> > > > poking XSM again.)
> > >
> > > And you have come up with some constructive comments which will be =
put
> > > in ASAP. Of course, registering these issues on
> > > http://dev.rectang.com/projects/xsm (click "new issue") will get a =
more
> > > "reliable" response ;)
> > >
> > > > dan
> > >
> > > Andy
> > >
> > > -------------------------------------------------------------------=
------
> > > Using Tomcat but need to do more? Need to support web services, sec=
urity?
> > > Get stuff done quickly with pre-integrated technology to make your =
job
> > > easier Download IBM WebSphere Application Server v.1.0.1 based on A=
pache
> > > Geronimo
> > > http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057=
&dat=3D121642
> > > _______________________________________________
> > > enlightenment-devel mailing list
> > > enlightenment-devel@...
> > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>=20
> -----------------------------------------------------------------------=
--
> Using Tomcat but need to do more? Need to support web services, securit=
y?
> Get stuff done quickly with pre-integrated technology to make your job =
easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geron=
imo
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat=
=3D121642
> _______________________________________________
> enlightenment-devel mailing list
> enlightenment-devel@...
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>=20
--=20
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) raster@...
=E8=A3=B8=E5=A5=BD=E5=A4=9A
Tokyo, Japan (=E6=9D=B1=E4=BA=AC =E6=97=A5=E6=9C=AC)

Hey Guys,
Sorry I've been away for so long. I'm still here, just in hiding. I
just wanted to chime in that I am fully willing to redo the site and do
what needs to be done to get that horrible pile of crap (90% of which I
wrote and hasn't been changing in 2+ years) fixed. I've made it clear
over the years that so long as we're using Rectang XSM I won't touch the
site. I used it a couple of times and the frustration, speed, and
capabilities of XSM are totally inexcusable. I have a great respect for
HandyAndE and mean no disrespect to him, but so long as XSM is in place
I'm not touching it anymore.
I've put out the offer a couple times over the years to dump the site
to static HTML and manage it like we used to, out of CVS, if nothing
else as a starter. I'm totally willing to make that migration if I get
a thumbs up. At least it would be a starting point and updates were
happening pretty frequently back prior to the XSM migration.
Ultimately I'd like to see all the divergent pages re-combined back
into a single E site, but politics always seem to cloud that discussion.
Anyway, I'm not dead, I'm still here and watching, although busy, but
who isn't. Say the word and I'll get back to work... the docs all need
refreshes too, all of which remains on my TODO list. In the meantime
I'm getting more and more Solaris people moved over to Enlightenment and
keepin' the buzz alive at shows and in the various non-Linux circles.
benr.
PS: If folks aren't looking at our stats, have a look, the site gets a
huge amount of activity, it deserves some love.
http://sourceforge.net/project/stats/?group_id=2&ugn=enlightenment

On Wed, 2006-09-20 at 16:59 -0700, Ben Rockwood wrote:
> Michael, chill. Lets look at the facts shall we:
>
> 1) Since moving to XSM updates have almost complete stopped. The
> changes in the last 2 years are all trivial. (Minus the redesign work.)
This has nothing to do with XSM as far as I can see - get-e.org uses XSM
and has lots of updates and folk working on it.
> 2) XSM is, speaking only for myself, slow and non-intuitive to work
> with. Simple news updates take 30 minutes or more due to rebuilds.
This is not XSM, but the fact that every single file is uploading over
SSH to sf.net which is very very slow. This can be improved, however, by
using a better delta on news items. A page with a large archive is not
being intelligently uploaded and what does need to be uploaded could be
backgrounded so you get the immediate response on the UI that folk
expect.
> 3) No one has stepped up to the plate to work within the current
> framework, and honestly I haven't heard anyone say they like it or are
> willing to maintain it in XSM.
erm - have you been reading this thread (or the last one, I forget)
there _are_ people that like XSM, OK they may not be in the majority but
there are enough to prove that it is not useless.
> 4) Final decisions on what happens with E.org is Raster's call. I
> haven't just yanked down XSM and done things "my way" because its not my
> call, its ultimately his. I brought up discussion about switching off
> of XSM over a year ago and the discussion fizzled out on the "leave it
> alone" note, I didn't rock the boat.
Whilst that is good of you it does seem to emphasise the whole "my way
or the highway" that michael pointed out before.
> 5) I don't care WHAT we use. Flat HTML is fast and easy and we'd have
> an updated site in less than a day even with the site on SF. So long as
> the choice is easier and faster to work with I really am not going to
> press for any particular solution.
Cool - when E gets it's own server XSM will speed up around 50 fold if
not more - have you even tried the demo set up at
http://rectang.com/Software/XSM/Demo/ ? that shows how fast it can run
when publishing locally.
> Bottom line, the site gets a noteworthy amount of traffic on a daily
> basis. No one is updating or maintaining the site. This wasn't the
> case prior to XSM, I'm not saying it was perfect but work was at least
> happening. Tell me what you want to move to and I'll do it. The point
> is here that I'm willing and able to do the work. Tell me what you want
> and that no one will freak out when I do it and off we go.
The reason there are no edits with XSM and there were before seems to be
simply that it was only you that made edits, so if you will not use XSM
then there will be no edits, seems pretty clear to me.
> ... besides, Michael, you know me. I don't tend to lone-gun things or
> dictate. I'm here to help, others will help, I believe, if we have a
> better framework, lets just get the site working reasonably again.
> I've had "Fix E.org" on my TODO list for over 2 years!!! I'd like to
> finally get on with things.
Using your preferred method "fixing" would require giving CVS write
access (and a CVS tutorial for the non-coders) to every person who
asked. Seems to me like a non-solution.
> benr.
>
Andy

On Thu, 21 Sep 2006 11:01:49 +0100 Andrew Williams <andy@...>
babbled:
> On Wed, 2006-09-20 at 16:59 -0700, Ben Rockwood wrote:
> > Michael, chill. Lets look at the facts shall we:
> >
> > 1) Since moving to XSM updates have almost complete stopped. The
> > changes in the last 2 years are all trivial. (Minus the redesign work.)
>
> This has nothing to do with XSM as far as I can see - get-e.org uses XSM
> and has lots of updates and folk working on it.
well it does - the fact that xsm runs on rectang and the www size is on sf.net
and the slowness in updates... this is due to the design of xsm and the fact
that we can't run it on sf.net and thus being forced into that situation - but
this doesn't mean that we can't fix this trivially by running it locally when
we move sites. :)
> > 2) XSM is, speaking only for myself, slow and non-intuitive to work
> > with. Simple news updates take 30 minutes or more due to rebuilds.
>
> This is not XSM, but the fact that every single file is uploading over
> SSH to sf.net which is very very slow. This can be improved, however, by
> using a better delta on news items. A page with a large archive is not
> being intelligently uploaded and what does need to be uploaded could be
> backgrounded so you get the immediate response on the UI that folk
> expect.
>
> > 3) No one has stepped up to the plate to work within the current
> > framework, and honestly I haven't heard anyone say they like it or are
> > willing to maintain it in XSM.
>
> erm - have you been reading this thread (or the last one, I forget)
> there _are_ people that like XSM, OK they may not be in the majority but
> there are enough to prove that it is not useless.
>
> > 4) Final decisions on what happens with E.org is Raster's call. I
> > haven't just yanked down XSM and done things "my way" because its not my
> > call, its ultimately his. I brought up discussion about switching off
> > of XSM over a year ago and the discussion fizzled out on the "leave it
> > alone" note, I didn't rock the boat.
>
> Whilst that is good of you it does seem to emphasise the whole "my way
> or the highway" that michael pointed out before.
>
> > 5) I don't care WHAT we use. Flat HTML is fast and easy and we'd have
> > an updated site in less than a day even with the site on SF. So long as
> > the choice is easier and faster to work with I really am not going to
> > press for any particular solution.
>
> Cool - when E gets it's own server XSM will speed up around 50 fold if
> not more - have you even tried the demo set up at
> http://rectang.com/Software/XSM/Demo/ ? that shows how fast it can run
> when publishing locally.
>
> > Bottom line, the site gets a noteworthy amount of traffic on a daily
> > basis. No one is updating or maintaining the site. This wasn't the
> > case prior to XSM, I'm not saying it was perfect but work was at least
> > happening. Tell me what you want to move to and I'll do it. The point
> > is here that I'm willing and able to do the work. Tell me what you want
> > and that no one will freak out when I do it and off we go.
>
> The reason there are no edits with XSM and there were before seems to be
> simply that it was only you that made edits, so if you will not use XSM
> then there will be no edits, seems pretty clear to me.
>
> > ... besides, Michael, you know me. I don't tend to lone-gun things or
> > dictate. I'm here to help, others will help, I believe, if we have a
> > better framework, lets just get the site working reasonably again.
> > I've had "Fix E.org" on my TODO list for over 2 years!!! I'd like to
> > finally get on with things.
>
> Using your preferred method "fixing" would require giving CVS write
> access (and a CVS tutorial for the non-coders) to every person who
> asked. Seems to me like a non-solution.
doing the www site via cvs - though a nice idea at the time and having certain
advantages - has dis-advantages too. i don't see us going back there. :)
> > benr.
> >
> Andy
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> enlightenment-devel mailing list
> enlightenment-devel@...
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
--
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) raster@...
裸好多
Tokyo, Japan (東京 日本)

On Thursday, 21 September 2006, at 15:23:15 (+0900),
Carsten Haitzler wrote:
> does anyone know of something that does the whole list of things we
> have mentioned we need - in one package that is solid and easy to
> use, reliable, efficient, secure etc.?
TikiWiki is one I use for a couple sites. It has wiki, forums, a FAQ
engine, a good authorization/permissions engine, and lots of other
features, many of which we'd never use, which can be turned off one by
one. Check out tikiwiki.org for more info; my two sites are
wiki.caosity.org and http://www.linuxvilleusa.com (pretty stale, but better
than E.org). ;-)
Michael
--
Michael Jennings (a.k.a. KainX) http://www.kainx.org/ <mej@...>
n + 1, Inc., http://www.nplus1.net/ Author, Eterm (www.eterm.org)
-----------------------------------------------------------------------
"What does not destroy me, makes me stronger."
-- Nietzsche, The Twilight of the Idols (1888)

On 9/21/06, Ben Rockwood <benr@...> wrote:
> Michael Jennings wrote:
> > On Thursday, 21 September 2006, at 15:23:15 (+0900),
> > Carsten Haitzler wrote:
> >
> >
> >> does anyone know of something that does the whole list of things we
> >> have mentioned we need - in one package that is solid and easy to
> >> use, reliable, efficient, secure etc.?
> >>
> >
> > TikiWiki is one I use for a couple sites. It has wiki, forums, a FAQ
> > engine, a good authorization/permissions engine, and lots of other
> > features, many of which we'd never use, which can be turned off one by
> > one. Check out tikiwiki.org for more info; my two sites are
> > wiki.caosity.org and http://www.linuxvilleusa.com (pretty stale, but better
> > than E.org). ;-)
> >
>
> I've been looking at TikiWiki lately. It looks really kool. I'd
> definately be willing to give it a try.
>
Be careful. Last I used TikiWiki it was a mess code-wise. Lots of
places for security holes to pop up and a wiki rendering engine that
was pure spaghetti. It may have gotten better in the year or so since
I last used it but....be careful. It has some egregious problems
before that allowed people to hijack your site very easily (similar to
the PHPBB bugs you may have heard about).
I would suggest possibly looking into bitweaver (formerly known as
TikiPro). They did a great job of refactoring and making the system
much nicer internally.
--
Justin Patrin

On Thursday, 21 September 2006, at 16:08:08 (-0700),
Justin Patrin wrote:
> Be careful. Last I used TikiWiki it was a mess code-wise. Lots of
> places for security holes to pop up and a wiki rendering engine that
> was pure spaghetti. It may have gotten better in the year or so
> since I last used it but....be careful. It has some egregious
> problems before that allowed people to hijack your site very easily
> (similar to the PHPBB bugs you may have heard about).
I've worked with the code too, and it's not great. But the engine
works. As far as security problems go, 3 or 4 have come up recently,
but it had been a long time prior to that. I keep a pretty close eye
on them too, and while we're undoubtedly going to fall victim from
time to time (no matter *what* CMS we use), adequate backups are the
best solution.
> I would suggest possibly looking into bitweaver (formerly known as
> TikiPro). They did a great job of refactoring and making the system
> much nicer internally.
I'm a bitweaver developer myself. There is no forum engine, no FAQ
engine, and major refactoring work is still going on. BW simply does
not fulfill the needs of this project yet.
Michael
--
Michael Jennings (a.k.a. KainX) http://www.kainx.org/ <mej@...>
n + 1, Inc., http://www.nplus1.net/ Author, Eterm (www.eterm.org)
-----------------------------------------------------------------------
"May the forces of evil become confused on the way to your house."
-- George Carlin

On Wednesday, 20 September 2006, at 10:51:36 (-0700),
Ben Rockwood wrote:
> I've made it clear over the years that so long as we're using
> Rectang XSM I won't touch the site. I used it a couple of times and
> the frustration, speed, and capabilities of XSM are totally
> inexcusable. I have a great respect for HandyAndE and mean no
> disrespect to him, but so long as XSM is in place I'm not touching
> it anymore.
So basically you'll only help if things are done the way you want them
to be. "My way, or the highway."
I think that attitude speaks for itself.
Michael
--
Michael Jennings (a.k.a. KainX) http://www.kainx.org/ <mej@...>
n + 1, Inc., http://www.nplus1.net/ Author, Eterm (www.eterm.org)
-----------------------------------------------------------------------
"But I dumped her. My motto is, 'Get out before they go down.'"
"That is so *not* my motto."
-- Monica Geller and Joey Tribbiani, "Friends"

I honestly don't see the need of having *everything* integrated, except for a
unified authentication system and maintenance
I see the need of an agile way of update information on the website (a wiki),
exchange opinions and support (a forum), and a formal channel for users to
present problems to the developers (a bug tracker).
I offer my help to unify the look and authentication systems of the best tool
for each job.
Unified authentication should be almost trivial to implement, the real problem
here is maintenance, having to track bugs and updates for several different
apps could be a bother, but not much more than tracking the bugs of obscure
modules that-might-be-unmaintained of a given CMS.
In my opinion trying to use an integrated system for everything will turn up
with a collection of half-baked services.
If you insist on using a integrated solution, then I guess Mambo/Joomla is the
most professional and complete choice I know about.

On Fri, 22 Sep 2006 14:34:55 -0300 Andres Blanc <andresblanc@...> babbled:
> I honestly don't see the need of having *everything* integrated, except for a
> unified authentication system and maintenance
>
> I see the need of an agile way of update information on the website (a wiki),
> exchange opinions and support (a forum), and a formal channel for users to
> present problems to the developers (a bug tracker).
> I offer my help to unify the look and authentication systems of the best tool
> for each job.
>
> Unified authentication should be almost trivial to implement, the real
> problem here is maintenance, having to track bugs and updates for several
> different apps could be a bother, but not much more than tracking the bugs of
> obscure modules that-might-be-unmaintained of a given CMS.
>
> In my opinion trying to use an integrated system for everything will turn up
> with a collection of half-baked services.
>
> If you insist on using a integrated solution, then I guess Mambo/Joomla is
> the most professional and complete choice I know about.
yes - the point is 1. minimal work for maintenance, bug fixes, security, etc.
2. minimal work to get this thing running
3. something that provides all the pieces we need so we don't have to go
inventing them.
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> enlightenment-devel mailing list
> enlightenment-devel@...
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
--
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) raster@...
裸好多
Tokyo, Japan (東京 日本)