Menu
▾
▴
sahana-agasti — Sahana Agasti Development Related Mailing List
You can subscribe to this list here.
| 2010 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(22) |
Jul
(30) |
Aug
(65) |
Sep
(29) |
Oct
(15) |
Nov
(10) |
Dec
(13) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2011 |
Jan
(33) |
Feb
(31) |
Mar
(32) |
Apr
(55) |
May
(26) |
Jun
(15) |
Jul
(7) |
Aug
(2) |
Sep
|
Oct
(3) |
Nov
(3) |
Dec
(2) |
| 2012 |
Jan
(3) |
Feb
(11) |
Mar
(35) |
Apr
(16) |
May
(7) |
Jun
(12) |
Jul
(5) |
Aug
(2) |
Sep
(3) |
Oct
|
Nov
(3) |
Dec
(6) |
| 2013 |
Jan
(6) |
Feb
(37) |
Mar
(16) |
Apr
(105) |
May
(37) |
Jun
(48) |
Jul
(33) |
Aug
(10) |
Sep
(23) |
Oct
(2) |
Nov
(4) |
Dec
(5) |
| 2014 |
Jan
(25) |
Feb
(50) |
Mar
(146) |
Apr
(15) |
May
(31) |
Jun
(42) |
Jul
(25) |
Aug
(23) |
Sep
(1) |
Oct
(4) |
Nov
|
Dec
|
| 2015 |
Jan
|
Feb
|
Mar
(6) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2021 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Shaharyar A. <aa...@ya...> - 2010-09-15 00:39:01
|
Hey, I am in the process of setting up an install of shana-agasti for a relief agency. I want to allow anonymous users to be able to view content (like shelter lists etc) but not be able to add new shelters or modify existing ones. I have tried various things in the Admin Security settings, and always end up with either All or None permissions for Anonymous user. Any help here would be appreicated. thanks -Sherry |
|
From: Chamindra de S. <cha...@op...> - 2010-09-11 11:55:52
|
Hi Chad, thanks for the teaser. I believe you do need to have something significant done before you can attract community and getting too much input might be counter productive at this stage. But when you do reach a milestone like defining the schema, I think it would be valuable to share it for wider input such that both NYC benefits from that experience and also you get the needed input that will keep the system future proof and generic enough to accommodate needs that are not NYC specific. However the unfortunate consequence of not communicating enough and not engaging the rest of the community is the perception that Agasti is dead and anyone who was hoping to join back to a PHP effort might just go away. Chamindra de Silva http://chamindra-de-silva.blogspot.com | http://twitter.com/ChamindraS On Thu, Sep 9, 2010 at 4:27 AM, <Cha...@ma...> wrote: > Chamindra, > > We can and will provide it shortly on lp however it's important to note > that this was a teaser. There are some conventions that we believe to be > workarounds and it changes and expands daily. If you believe providing that > is beneficial, we can do so but we'll need to think of the best way to > structure conversations to ensure that they happen around the current daily > build and not a prior one. > > Also, as a small word of advice to anyone using doctrine--if you dump it > into your favorite db and expect the models to reflect the db schema you > might be unpleasantly surprised. Doctrine models are built first and contain > the relationships and constraints. From those models it designs the schema. > This allows doctrine to enforce constraints on db engine's that don't. > Effectively, this means that relationships created in the db are more of a > courtesy or second line of defense but should not be considered canonical. > > We actually have some work planned this sprint to try other methods than > the few we see as potential workarounds (or perhaps just Doctrine > limitations). If something good comes of that there could be massive > changes. If you believe it's important to release before that I'll speak > with the team about doing so. > > Regards, > Chad Heuschober > CUNY School of Professional Studies > 101 West 31st Street, 7th Floor > New York, NY 10001 > cha...@ma... > 212.652.2886 > ------------------------------ > > * From: *Chamindra de Silva [cha...@op...] > * Sent: *09/09/2010 03:30 AM ZE5B > > * To: *ag...@li... > * Subject: *Re: [sahana-agasti] Mayon Schema... > > Can you share the structure in YML in the WIKI as it might be easier to > read and comment on? I do realize you have strict deadlines and milestones > for NYC, but it is important that any collaboration be done using mechanisms > where people can participate. There is a wealth of knowledge and experience > in the Sahana community that you should capitalize on to deliver a better > system to NYC or you really are not making the most of Sahana Open Source > project nature. > > Chamindra de Silva > http://chamindra-de-silva.blogspot.com | http://twitter.com/ChamindraS > > > On Fri, Sep 3, 2010 at 2:39 AM, <Cha...@ma...> wrote: > >> >> >> Greg, >> >> Thanks for the suggestion. For any Mayon development we highly recommend >> that users stay far far away from workbench or, frankly, any db-specific >> tools -- even command line ones. It is recommended that all database >> interaction happen in Doctrine itself (YML) or with tools that are built >> for YML compliance. We wasted some time when we found out just how badly >> workbench can wreck a symfony system. >> >> It is possible to reverse engineer an ER diagram out of a post-install db >> with workbench but the datatypes aren't necessarily the same and it takes >> too long to move the tables around into something that's remotely well >> organized. This is an early draft so I expect we'll put something nicer >> out >> when we get closer to an early alpha. >> >> Best, >> Chad Heuschober >> CUNY School of Professional Studies >> 101 West 31st St. >> New York, NY 10001 >> Phone: (212) 652-2886 >> E-mail: cha...@ma... >> >> >> >> Greg Miernicki >> <miernickig@mail. >> nih.gov> To >> ag...@li... >> 09/02/2010 04:36 cc >> PM >> Subject >> Re: [sahana-agasti] Mayon Schema... >> Please respond to >> ag...@li...ha >> nafoundation.org >> >> >> >> >> >> >> >> Sounds like you guys may want to look into MySQL WorkBench (free): >> http://wb.mysql.com/?page_id=35 >> >> But thanks for the scans, Chad. We'll take a look over them so as to keep >> in mind what we are developing and how it should interact with Agasti 2.0 >> in the future. >> >> >> -Greg >> >> On Thu, Sep 2, 2010 at 15:31, <Cha...@ma...> wrote: >> >> >> Hi Greg, >> >> Unfortunately the tool we have doesn't allow us to output anything higher >> unless we print (to paper) on multiple pages. I did that, scanned the >> results, and attached a pdf to the wiki page. >> >> Regards, >> Chad Heuschober >> CUNY School of Professional Studies >> 101 West 31st St. >> New York, NY 10001 >> Phone: (212) 652-2886 >> E-mail: cha...@ma... >> >> >> >> Greg Miernicki <miernickig@mail. >> nih.gov> >> To >> ag...@li... >> 09/02/2010 02:49 >> cc >> PM >> Subject Re: [sahana-agasti] Mayon >> Schema... Please respond to >> ag...@li...ha nafoundation.org >> >> >> >> >> >> >> >> Seems like the resolution is a little low on the image. Viewing the full >> size image on the wiki: >> >> >> http://wiki.sahanafoundation.org/lib/exe/fetch.php/agasti:mayon:orm_design.png?cache= >> >> >> leaves the text too small to read at all. Could we get an SVG or larger >> image perhaps? >> >> -Greg >> >> On Thu, Sep 2, 2010 at 14:41, <Cha...@ma...> >> wrote: Hello Community, The SPS team has posted an early draft of our >> person-management elements of the schema, for the curious. >> http://wiki.sahanafoundation.org/doku.php/agasti:mayon:schema >> >> This is still under heavy development and reflects a number of >> choices we've been forced to make because of some odd behaviour or >> limitations within Doctrine but it's there! This is, as the Symfony >> founder recommends, a 'fat-model' design which should minimize some of >> the headaches of a future upgrade to 2.0. Also please note that support >> for scenarios, staff, and clients is still be worked on and has not been >> intentionally omitted. Ideally, this heavily normalized design should >> scale forward well into the future and offer plenty of opportunities for >> plugin and module development. Regards, Chad Heuschober CUNY School >> of >> Professional >> Studies >> ------------------------------------------------------------------------------ >> This >> SF.net Dev2Dev email is sponsored by: Show off your parallel >> programming >> skills. Enter the Intel(R) Threading Challenge 2010. >> http://p.sf.net/sfu/intel-thread-sfd >> _______________________________________________ sahana-agasti mailing >> list sah...@li... >> https://lists.sourceforge.net/lists/listinfo/sahana-agasti >> >> >> >> -- >> Greg Miernicki >> Software Scientist >> National Library of Medicine >> 410-696-4623 >> >> ------------------------------------------------------------------------------ >> >> >> This SF.net Dev2Dev email is sponsored by: >> >> Show off your parallel programming skills. >> Enter the Intel(R) Threading Challenge 2010. >> http://p.sf.net/sfu/intel-thread-sfd >> _______________________________________________ >> sahana-agasti mailing list >> sah...@li... >> https://lists.sourceforge.net/lists/listinfo/sahana-agasti >> >> >> >> >> ------------------------------------------------------------------------------ >> >> This SF.net Dev2Dev email is sponsored by: >> >> Show off your parallel programming skills. >> Enter the Intel(R) Threading Challenge 2010. >> http://p.sf.net/sfu/intel-thread-sfd >> _______________________________________________ >> sahana-agasti mailing list >> sah...@li... >> https://lists.sourceforge.net/lists/listinfo/sahana-agasti >> >> >> >> -- >> Greg Miernicki >> Software Scientist >> National Library of Medicine >> 410-696-4623 >> >> ------------------------------------------------------------------------------ >> >> This SF.net Dev2Dev email is sponsored by: >> >> Show off your parallel programming skills. >> Enter the Intel(R) Threading Challenge 2010. >> http://p.sf.net/sfu/intel-thread-sfd >> _______________________________________________ >> sahana-agasti mailing list >> sah...@li... >> https://lists.sourceforge.net/lists/listinfo/sahana-agasti >> >> >> >> >> ------------------------------------------------------------------------------ >> This SF.net Dev2Dev email is sponsored by: >> >> Show off your parallel programming skills. >> Enter the Intel(R) Threading Challenge 2010. >> http://p.sf.net/sfu/intel-thread-sfd >> _______________________________________________ >> sahana-agasti mailing list >> sah...@li... >> https://lists.sourceforge.net/lists/listinfo/sahana-agasti >> > > > > ------------------------------------------------------------------------------ > This SF.net Dev2Dev email is sponsored by: > > Show off your parallel programming skills. > Enter the Intel(R) Threading Challenge 2010. > http://p.sf.net/sfu/intel-thread-sfd > _______________________________________________ > sahana-agasti mailing list > sah...@li... > https://lists.sourceforge.net/lists/listinfo/sahana-agasti > > > ------------------------------------------------------------------------------ > This SF.net Dev2Dev email is sponsored by: > > Show off your parallel programming skills. > Enter the Intel(R) Threading Challenge 2010. > http://p.sf.net/sfu/intel-thread-sfd > _______________________________________________ > sahana-agasti mailing list > sah...@li... > https://lists.sourceforge.net/lists/listinfo/sahana-agasti > > |
|
From: <Cha...@ma...> - 2010-09-08 22:57:57
|
------------------------------------------------------------------------------ This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd |
|
From: Chamindra de S. <cha...@op...> - 2010-09-08 22:00:42
|
Can you share the structure in YML in the WIKI as it might be easier to read and comment on? I do realize you have strict deadlines and milestones for NYC, but it is important that any collaboration be done using mechanisms where people can participate. There is a wealth of knowledge and experience in the Sahana community that you should capitalize on to deliver a better system to NYC or you really are not making the most of Sahana Open Source project nature. Chamindra de Silva http://chamindra-de-silva.blogspot.com | http://twitter.com/ChamindraS On Fri, Sep 3, 2010 at 2:39 AM, <Cha...@ma...> wrote: > > > Greg, > > Thanks for the suggestion. For any Mayon development we highly recommend > that users stay far far away from workbench or, frankly, any db-specific > tools -- even command line ones. It is recommended that all database > interaction happen in Doctrine itself (YML) or with tools that are built > for YML compliance. We wasted some time when we found out just how badly > workbench can wreck a symfony system. > > It is possible to reverse engineer an ER diagram out of a post-install db > with workbench but the datatypes aren't necessarily the same and it takes > too long to move the tables around into something that's remotely well > organized. This is an early draft so I expect we'll put something nicer out > when we get closer to an early alpha. > > Best, > Chad Heuschober > CUNY School of Professional Studies > 101 West 31st St. > New York, NY 10001 > Phone: (212) 652-2886 > E-mail: cha...@ma... > > > > Greg Miernicki > <miernickig@mail. > nih.gov> To > ag...@li... > 09/02/2010 04:36 cc > PM > Subject > Re: [sahana-agasti] Mayon Schema... > Please respond to > ag...@li...ha > nafoundation.org > > > > > > > > Sounds like you guys may want to look into MySQL WorkBench (free): > http://wb.mysql.com/?page_id=35 > > But thanks for the scans, Chad. We'll take a look over them so as to keep > in mind what we are developing and how it should interact with Agasti 2.0 > in the future. > > > -Greg > > On Thu, Sep 2, 2010 at 15:31, <Cha...@ma...> wrote: > > > Hi Greg, > > Unfortunately the tool we have doesn't allow us to output anything higher > unless we print (to paper) on multiple pages. I did that, scanned the > results, and attached a pdf to the wiki page. > > Regards, > Chad Heuschober > CUNY School of Professional Studies > 101 West 31st St. > New York, NY 10001 > Phone: (212) 652-2886 > E-mail: cha...@ma... > > > > Greg Miernicki <miernickig@mail. > nih.gov> > To > ag...@li... > 09/02/2010 02:49 > cc > PM > Subject Re: [sahana-agasti] Mayon > Schema... Please respond to > ag...@li...ha nafoundation.org > > > > > > > > Seems like the resolution is a little low on the image. Viewing the full > size image on the wiki: > > > http://wiki.sahanafoundation.org/lib/exe/fetch.php/agasti:mayon:orm_design.png?cache= > > > leaves the text too small to read at all. Could we get an SVG or larger > image perhaps? > > -Greg > > On Thu, Sep 2, 2010 at 14:41, <Cha...@ma...> > wrote: Hello Community, The SPS team has posted an early draft of our > person-management elements of the schema, for the curious. > http://wiki.sahanafoundation.org/doku.php/agasti:mayon:schema > > This is still under heavy development and reflects a number of > choices we've been forced to make because of some odd behaviour or > limitations within Doctrine but it's there! This is, as the Symfony > founder recommends, a 'fat-model' design which should minimize some of > the headaches of a future upgrade to 2.0. Also please note that support > for scenarios, staff, and clients is still be worked on and has not been > intentionally omitted. Ideally, this heavily normalized design should > scale forward well into the future and offer plenty of opportunities for > plugin and module development. Regards, Chad Heuschober CUNY School of > Professional > Studies > ------------------------------------------------------------------------------ > This > SF.net Dev2Dev email is sponsored by: Show off your parallel programming > skills. Enter the Intel(R) Threading Challenge 2010. > http://p.sf.net/sfu/intel-thread-sfd > _______________________________________________ sahana-agasti mailing > list sah...@li... > https://lists.sourceforge.net/lists/listinfo/sahana-agasti > > > > -- > Greg Miernicki > Software Scientist > National Library of Medicine > 410-696-4623 > > ------------------------------------------------------------------------------ > > > This SF.net Dev2Dev email is sponsored by: > > Show off your parallel programming skills. > Enter the Intel(R) Threading Challenge 2010. > http://p.sf.net/sfu/intel-thread-sfd > _______________________________________________ > sahana-agasti mailing list > sah...@li... > https://lists.sourceforge.net/lists/listinfo/sahana-agasti > > > > > ------------------------------------------------------------------------------ > > This SF.net Dev2Dev email is sponsored by: > > Show off your parallel programming skills. > Enter the Intel(R) Threading Challenge 2010. > http://p.sf.net/sfu/intel-thread-sfd > _______________________________________________ > sahana-agasti mailing list > sah...@li... > https://lists.sourceforge.net/lists/listinfo/sahana-agasti > > > > -- > Greg Miernicki > Software Scientist > National Library of Medicine > 410-696-4623 > > ------------------------------------------------------------------------------ > > This SF.net Dev2Dev email is sponsored by: > > Show off your parallel programming skills. > Enter the Intel(R) Threading Challenge 2010. > http://p.sf.net/sfu/intel-thread-sfd > _______________________________________________ > sahana-agasti mailing list > sah...@li... > https://lists.sourceforge.net/lists/listinfo/sahana-agasti > > > > > ------------------------------------------------------------------------------ > This SF.net Dev2Dev email is sponsored by: > > Show off your parallel programming skills. > Enter the Intel(R) Threading Challenge 2010. > http://p.sf.net/sfu/intel-thread-sfd > _______________________________________________ > sahana-agasti mailing list > sah...@li... > https://lists.sourceforge.net/lists/listinfo/sahana-agasti > |
|
From: Greg M. <mie...@ma...> - 2010-09-07 17:28:49
|
I would suggest you file a bug report for this on Launchpad >> http://agasti.sahanafoundation.org On Sat, Sep 4, 2010 at 00:52, Elson Solano <jim...@ya...> wrote: > Hi, Good Day! > > I'm having a problem on Volunteer Management Module. > Everytime I clicked on the Volunteer Management Module, > I see a fatal error: > *Fatal error*: Call to a member function MoveNext() on a non-object in * > /mod/vm/model/dao.php* on line *155 > > *I'm working on Agasti 0.6.3 > > When I tried to run my sahana in my localhost, there's no problem in > Volunteer Management but when I started to upload it in the internet, that > is where that fatal error shows up. > > Hoping for a reply. > Thanks! > > > > ------------------------------------------------------------------------------ > This SF.net Dev2Dev email is sponsored by: > > Show off your parallel programming skills. > Enter the Intel(R) Threading Challenge 2010. > http://p.sf.net/sfu/intel-thread-sfd > _______________________________________________ > sahana-agasti mailing list > sah...@li... > https://lists.sourceforge.net/lists/listinfo/sahana-agasti > > -- Greg Miernicki Software Scientist National Library of Medicine 410-696-4623 |
|
From: Elson S. <jim...@ya...> - 2010-09-04 04:52:13
|
Hi, Good Day!
I'm having a problem on Volunteer Management Module.
Everytime I clicked on the Volunteer Management Module,
I see a fatal error:
Fatal error: Call to a member function MoveNext() on a non-object in
/mod/vm/model/dao.php on line 155
I'm working on Agasti 0.6.3
When I tried to run my sahana in my localhost, there's no problem in Volunteer
Management but when I started to upload it in the internet, that is where that
fatal error shows up.
Hoping for a reply.
Thanks!
|
|
From: <Cha...@ma...> - 2010-09-03 20:20:09
|
Glenn,
That would be fantastic. It *should* be seamless but such things are rarely
perfect.
Best,
Chad Heuschober
CUNY School of Professional Studies
101 West 31st St.
New York, NY 10001
Phone: (212) 652-2886
E-mail: cha...@ma...
"Pearson, Glenn
(NIH/NLM/LHC)
[C]" To
<gpe...@ma... "'ag...@li...
h.gov> '"
<ag...@li...>
09/03/2010 04:07 cc
PM
Subject
Re: [sahana-agasti] Mayon Schema...
Please respond to
ag...@li...ha
nafoundation.org
No promises, but NLM could probably do a SQL Server port at some point
farther downstream, when Mayon's in beta. We have the licenses and talent.
Oracle would be a bit more of a stretch.
- Glenn
From: Robby O'Connor [mailto:rob...@gm...]
Sent: Friday, September 03, 2010 2:44 AM
To: ag...@li...
Subject: Re: [sahana-agasti] Mayon Schema...
On 9/3/2010 12:14 AM, Cha...@ma... wrote:
To address your second question, we are writing this according to
doctrine's guidelines so it "should" support every db backend that
doctrine supports. It's a pretty extensive and impressive list. Of
what we can test, I expect we'll be looking at postgres and mysql
installs with a focus on mysql. This is partially due to a lack of
human resources to support more and partially due to a lack of
software licenses (Oracle and MSSQL licenses do not come cheaply!)
Sorry to pipe in (since I'm an eden guy): Doesn't Oracle and/or MS offer
Open Source licenses? Surely they'd be (potentially?) willing to do it
especially in the case of Sahana?
------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:
Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
_______________________________________________
sahana-agasti mailing list
sah...@li...
https://lists.sourceforge.net/lists/listinfo/sahana-agasti
|
|
From: Pearson, G. (NIH/NLM/L. [C] <gpe...@ma...> - 2010-09-03 20:09:01
|
No promises, but NLM could probably do a SQL Server port at some point farther downstream, when Mayon's in beta. We have the licenses and talent. Oracle would be a bit more of a stretch. - Glenn ________________________________ From: Robby O'Connor [mailto:rob...@gm...] Sent: Friday, September 03, 2010 2:44 AM To: ag...@li... Subject: Re: [sahana-agasti] Mayon Schema... On 9/3/2010 12:14 AM, Cha...@ma...<mailto:Cha...@ma...> wrote: To address your second question, we are writing this according to doctrine's guidelines so it "should" support every db backend that doctrine supports. It's a pretty extensive and impressive list. Of what we can test, I expect we'll be looking at postgres and mysql installs with a focus on mysql. This is partially due to a lack of human resources to support more and partially due to a lack of software licenses (Oracle and MSSQL licenses do not come cheaply!) Sorry to pipe in (since I'm an eden guy): Doesn't Oracle and/or MS offer Open Source licenses? Surely they'd be (potentially?) willing to do it especially in the case of Sahana? |
|
From: Robby O'C. <rob...@gm...> - 2010-09-03 06:44:33
|
On 9/3/2010 12:14 AM, Cha...@ma... wrote: > > To address your second question, we are writing this according to > doctrine's guidelines so it "should" support every db backend that > doctrine supports. It's a pretty extensive and impressive list. Of > what we can test, I expect we'll be looking at postgres and mysql > installs with a focus on mysql. This is partially due to a lack of > human resources to support more and partially due to a lack of > software licenses (Oracle and MSSQL licenses do not come cheaply!) > Sorry to pipe in (since I'm an eden guy): Doesn't Oracle and/or MS offer Open Source licenses? Surely they'd be (potentially?) willing to do it especially in the case of Sahana? |
|
From: <Cha...@ma...> - 2010-09-03 04:14:46
|
------------------------------------------------------------------------------ This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd |
|
From: Greg M. <mie...@ma...> - 2010-09-02 21:30:38
|
Chad, You're correct that WB is strongly tied to MySQL; which is not a principle of Agasti. However, as far as creating an ER diagram that can be exported in any number of formats, I have yet to find something on par with it. Which is the only reason I was suggesting it. Out of curiosity, have you guys nailed down which DB systems will be supported for Agasti 2.0 ? -Greg On Thu, Sep 2, 2010 at 17:09, <Cha...@ma...> wrote: > > > Greg, > > Thanks for the suggestion. For any Mayon development we highly recommend > that users stay far far away from workbench or, frankly, any db-specific > tools -- even command line ones. It is recommended that all database > interaction happen in Doctrine itself (YML) or with tools that are built > for YML compliance. We wasted some time when we found out just how badly > workbench can wreck a symfony system. > > It is possible to reverse engineer an ER diagram out of a post-install db > with workbench but the datatypes aren't necessarily the same and it takes > too long to move the tables around into something that's remotely well > organized. This is an early draft so I expect we'll put something nicer out > when we get closer to an early alpha. > > Best, > Chad Heuschober > CUNY School of Professional Studies > 101 West 31st St. > New York, NY 10001 > Phone: (212) 652-2886 > E-mail: cha...@ma... > > > > Greg Miernicki > <miernickig@mail. > nih.gov> To > ag...@li... > 09/02/2010 04:36 cc > PM > Subject > Re: [sahana-agasti] Mayon Schema... > Please respond to > ag...@li...ha > nafoundation.org > > > > > > > > Sounds like you guys may want to look into MySQL WorkBench (free): > http://wb.mysql.com/?page_id=35 > > But thanks for the scans, Chad. We'll take a look over them so as to keep > in mind what we are developing and how it should interact with Agasti 2.0 > in the future. > > > -Greg > > On Thu, Sep 2, 2010 at 15:31, <Cha...@ma...> wrote: > > > Hi Greg, > > Unfortunately the tool we have doesn't allow us to output anything higher > unless we print (to paper) on multiple pages. I did that, scanned the > results, and attached a pdf to the wiki page. > > Regards, > Chad Heuschober > CUNY School of Professional Studies > 101 West 31st St. > New York, NY 10001 > Phone: (212) 652-2886 > E-mail: cha...@ma... > > > > Greg Miernicki <miernickig@mail. > nih.gov> > To > ag...@li... > 09/02/2010 02:49 > cc > PM > Subject Re: [sahana-agasti] Mayon > Schema... Please respond to > ag...@li...ha nafoundation.org > > > > > > > > Seems like the resolution is a little low on the image. Viewing the full > size image on the wiki: > > > http://wiki.sahanafoundation.org/lib/exe/fetch.php/agasti:mayon:orm_design.png?cache= > > > leaves the text too small to read at all. Could we get an SVG or larger > image perhaps? > > -Greg > > On Thu, Sep 2, 2010 at 14:41, <Cha...@ma...> > wrote: Hello Community, The SPS team has posted an early draft of our > person-management elements of the schema, for the curious. > http://wiki.sahanafoundation.org/doku.php/agasti:mayon:schema > > This is still under heavy development and reflects a number of > choices we've been forced to make because of some odd behaviour or > limitations within Doctrine but it's there! This is, as the Symfony > founder recommends, a 'fat-model' design which should minimize some of > the headaches of a future upgrade to 2.0. Also please note that support > for scenarios, staff, and clients is still be worked on and has not been > intentionally omitted. Ideally, this heavily normalized design should > scale forward well into the future and offer plenty of opportunities for > plugin and module development. Regards, Chad Heuschober CUNY School of > Professional > Studies > ------------------------------------------------------------------------------ > This > SF.net Dev2Dev email is sponsored by: Show off your parallel programming > skills. Enter the Intel(R) Threading Challenge 2010. > http://p.sf.net/sfu/intel-thread-sfd > _______________________________________________ sahana-agasti mailing > list sah...@li... > https://lists.sourceforge.net/lists/listinfo/sahana-agasti > > > > -- > Greg Miernicki > Software Scientist > National Library of Medicine > 410-696-4623 > > ------------------------------------------------------------------------------ > > > This SF.net Dev2Dev email is sponsored by: > > Show off your parallel programming skills. > Enter the Intel(R) Threading Challenge 2010. > http://p.sf.net/sfu/intel-thread-sfd > _______________________________________________ > sahana-agasti mailing list > sah...@li... > https://lists.sourceforge.net/lists/listinfo/sahana-agasti > > > > > ------------------------------------------------------------------------------ > > This SF.net Dev2Dev email is sponsored by: > > Show off your parallel programming skills. > Enter the Intel(R) Threading Challenge 2010. > http://p.sf.net/sfu/intel-thread-sfd > _______________________________________________ > sahana-agasti mailing list > sah...@li... > https://lists.sourceforge.net/lists/listinfo/sahana-agasti > > > > -- > Greg Miernicki > Software Scientist > National Library of Medicine > 410-696-4623 > > ------------------------------------------------------------------------------ > > This SF.net Dev2Dev email is sponsored by: > > Show off your parallel programming skills. > Enter the Intel(R) Threading Challenge 2010. > http://p.sf.net/sfu/intel-thread-sfd > _______________________________________________ > sahana-agasti mailing list > sah...@li... > https://lists.sourceforge.net/lists/listinfo/sahana-agasti > > > > > ------------------------------------------------------------------------------ > This SF.net Dev2Dev email is sponsored by: > > Show off your parallel programming skills. > Enter the Intel(R) Threading Challenge 2010. > http://p.sf.net/sfu/intel-thread-sfd > _______________________________________________ > sahana-agasti mailing list > sah...@li... > https://lists.sourceforge.net/lists/listinfo/sahana-agasti > -- Greg Miernicki Software Scientist National Library of Medicine 410-696-4623 |
|
From: <Cha...@ma...> - 2010-09-02 21:09:26
|
Greg,
Thanks for the suggestion. For any Mayon development we highly recommend
that users stay far far away from workbench or, frankly, any db-specific
tools -- even command line ones. It is recommended that all database
interaction happen in Doctrine itself (YML) or with tools that are built
for YML compliance. We wasted some time when we found out just how badly
workbench can wreck a symfony system.
It is possible to reverse engineer an ER diagram out of a post-install db
with workbench but the datatypes aren't necessarily the same and it takes
too long to move the tables around into something that's remotely well
organized. This is an early draft so I expect we'll put something nicer out
when we get closer to an early alpha.
Best,
Chad Heuschober
CUNY School of Professional Studies
101 West 31st St.
New York, NY 10001
Phone: (212) 652-2886
E-mail: cha...@ma...
Greg Miernicki
<miernickig@mail.
nih.gov> To
ag...@li...
09/02/2010 04:36 cc
PM
Subject
Re: [sahana-agasti] Mayon Schema...
Please respond to
ag...@li...ha
nafoundation.org
Sounds like you guys may want to look into MySQL WorkBench (free):
http://wb.mysql.com/?page_id=35
But thanks for the scans, Chad. We'll take a look over them so as to keep
in mind what we are developing and how it should interact with Agasti 2.0
in the future.
-Greg
On Thu, Sep 2, 2010 at 15:31, <Cha...@ma...> wrote:
Hi Greg,
Unfortunately the tool we have doesn't allow us to output anything higher
unless we print (to paper) on multiple pages. I did that, scanned the
results, and attached a pdf to the wiki page.
Regards,
Chad Heuschober
CUNY School of Professional Studies
101 West 31st St.
New York, NY 10001
Phone: (212) 652-2886
E-mail: cha...@ma...
Greg Miernicki |
|
From: Greg M. <mie...@ma...> - 2010-09-02 20:37:14
|
Sounds like you guys may want to look into MySQL WorkBench (free): http://wb.mysql.com/?page_id=35 <http://wb.mysql.com/?page_id=35>But thanks for the scans, Chad. We'll take a look over them so as to keep in mind what we are developing and how it should interact with Agasti 2.0 in the future. -Greg On Thu, Sep 2, 2010 at 15:31, <Cha...@ma...> wrote: > > > Hi Greg, > > Unfortunately the tool we have doesn't allow us to output anything higher > unless we print (to paper) on multiple pages. I did that, scanned the > results, and attached a pdf to the wiki page. > > Regards, > Chad Heuschober > CUNY School of Professional Studies > 101 West 31st St. > New York, NY 10001 > Phone: (212) 652-2886 > E-mail: cha...@ma... > > > > Greg Miernicki > <miernickig@mail. > nih.gov> To > ag...@li... > 09/02/2010 02:49 cc > PM > Subject > Re: [sahana-agasti] Mayon Schema... > Please respond to > ag...@li...ha > nafoundation.org > > > > > > > > Seems like the resolution is a little low on the image. Viewing the full > size image on the wiki: > > > http://wiki.sahanafoundation.org/lib/exe/fetch.php/agasti:mayon:orm_design.png?cache= > > leaves the text too small to read at all. Could we get an SVG or larger > image perhaps? > > -Greg > > On Thu, Sep 2, 2010 at 14:41, <Cha...@ma...> wrote: > > Hello Community, > > The SPS team has posted an early draft of our person-management elements > of > the schema, for the curious. > http://wiki.sahanafoundation.org/doku.php/agasti:mayon:schema > > This is still under heavy development and reflects a number of choices > we've been forced to make because of some odd behaviour or limitations > within Doctrine but it's there! > > This is, as the Symfony founder recommends, a 'fat-model' design which > should minimize some of the headaches of a future upgrade to 2.0. Also > please note that support for scenarios, staff, and clients is still be > worked on and has not been intentionally omitted. Ideally, this heavily > normalized design should scale forward well into the future and offer > plenty of opportunities for plugin and module development. > > Regards, > Chad Heuschober > CUNY School of Professional Studies > > > > ------------------------------------------------------------------------------ > > This SF.net Dev2Dev email is sponsored by: > > Show off your parallel programming skills. > Enter the Intel(R) Threading Challenge 2010. > http://p.sf.net/sfu/intel-thread-sfd > _______________________________________________ > sahana-agasti mailing list > sah...@li... > https://lists.sourceforge.net/lists/listinfo/sahana-agasti > > > > -- > Greg Miernicki > Software Scientist > National Library of Medicine > 410-696-4623 > > ------------------------------------------------------------------------------ > > This SF.net Dev2Dev email is sponsored by: > > Show off your parallel programming skills. > Enter the Intel(R) Threading Challenge 2010. > http://p.sf.net/sfu/intel-thread-sfd > _______________________________________________ > sahana-agasti mailing list > sah...@li... > https://lists.sourceforge.net/lists/listinfo/sahana-agasti > > > > > ------------------------------------------------------------------------------ > This SF.net Dev2Dev email is sponsored by: > > Show off your parallel programming skills. > Enter the Intel(R) Threading Challenge 2010. > http://p.sf.net/sfu/intel-thread-sfd > _______________________________________________ > sahana-agasti mailing list > sah...@li... > https://lists.sourceforge.net/lists/listinfo/sahana-agasti > -- Greg Miernicki Software Scientist National Library of Medicine 410-696-4623 |
|
From: <Cha...@ma...> - 2010-09-02 19:31:19
|
Hi Greg,
Unfortunately the tool we have doesn't allow us to output anything higher
unless we print (to paper) on multiple pages. I did that, scanned the
results, and attached a pdf to the wiki page.
Regards,
Chad Heuschober
CUNY School of Professional Studies
101 West 31st St.
New York, NY 10001
Phone: (212) 652-2886
E-mail: cha...@ma...
Greg Miernicki
<miernickig@mail.
nih.gov> To
ag...@li...
09/02/2010 02:49 cc
PM
Subject
Re: [sahana-agasti] Mayon Schema...
Please respond to
ag...@li...ha
nafoundation.org
Seems like the resolution is a little low on the image. Viewing the full
size image on the wiki:
http://wiki.sahanafoundation.org/lib/exe/fetch.php/agasti:mayon:orm_design.png?cache=
leaves the text too small to read at all. Could we get an SVG or larger
image perhaps?
-Greg
On Thu, Sep 2, 2010 at 14:41, <Cha...@ma...> wrote:
Hello Community,
The SPS team has posted an early draft of our person-management elements
of
the schema, for the curious.
http://wiki.sahanafoundation.org/doku.php/agasti:mayon:schema
This is still under heavy development and reflects a number of choices
we've been forced to make because of some odd behaviour or limitations
within Doctrine but it's there!
This is, as the Symfony founder recommends, a 'fat-model' design which
should minimize some of the headaches of a future upgrade to 2.0. Also
please note that support for scenarios, staff, and clients is still be
worked on and has not been intentionally omitted. Ideally, this heavily
normalized design should scale forward well into the future and offer
plenty of opportunities for plugin and module development.
Regards,
Chad Heuschober
CUNY School of Professional Studies
------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:
Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
_______________________________________________
sahana-agasti mailing list
sah...@li...
https://lists.sourceforge.net/lists/listinfo/sahana-agasti
--
Greg Miernicki
Software Scientist
National Library of Medicine
410-696-4623
------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:
Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
_______________________________________________
sahana-agasti mailing list
sah...@li...
https://lists.sourceforge.net/lists/listinfo/sahana-agasti
|
|
From: Pearson, G. (NIH/NLM/L. [C] <gpe...@ma...> - 2010-09-02 19:25:43
|
Chad, any chance of posting a version of this that people could actually read? Even blown up, it's a strain with this pixelated/smashed font. Can your generation tool put each group on a separate page (with annotations for off-page links)? - Glenn -----Original Message----- From: Cha...@ma... [mailto:Cha...@ma...] Sent: Thursday, September 02, 2010 2:41 PM To: ag...@li... Subject: [sahana-agasti] Mayon Schema... Hello Community, The SPS team has posted an early draft of our person-management elements of the schema, for the curious. http://wiki.sahanafoundation.org/doku.php/agasti:mayon:schema This is still under heavy development and reflects a number of choices we've been forced to make because of some odd behaviour or limitations within Doctrine but it's there! This is, as the Symfony founder recommends, a 'fat-model' design which should minimize some of the headaches of a future upgrade to 2.0. Also please note that support for scenarios, staff, and clients is still be worked on and has not been intentionally omitted. Ideally, this heavily normalized design should scale forward well into the future and offer plenty of opportunities for plugin and module development. Regards, Chad Heuschober CUNY School of Professional Studies ------------------------------------------------------------------------------ This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd _______________________________________________ sahana-agasti mailing list sah...@li... https://lists.sourceforge.net/lists/listinfo/sahana-agasti |
|
From: Greg M. <mie...@ma...> - 2010-09-02 18:50:17
|
Seems like the resolution is a little low on the image. Viewing the full size image on the wiki: http://wiki.sahanafoundation.org/lib/exe/fetch.php/agasti:mayon:orm_design.png?cache= <http://wiki.sahanafoundation.org/lib/exe/fetch.php/agasti:mayon:orm_design.png?cache=>leaves the text too small to read at all. Could we get an SVG or larger image perhaps? -Greg On Thu, Sep 2, 2010 at 14:41, <Cha...@ma...> wrote: > > Hello Community, > > The SPS team has posted an early draft of our person-management elements of > the schema, for the curious. > http://wiki.sahanafoundation.org/doku.php/agasti:mayon:schema > > This is still under heavy development and reflects a number of choices > we've been forced to make because of some odd behaviour or limitations > within Doctrine but it's there! > > This is, as the Symfony founder recommends, a 'fat-model' design which > should minimize some of the headaches of a future upgrade to 2.0. Also > please note that support for scenarios, staff, and clients is still be > worked on and has not been intentionally omitted. Ideally, this heavily > normalized design should scale forward well into the future and offer > plenty of opportunities for plugin and module development. > > Regards, > Chad Heuschober > CUNY School of Professional Studies > > > > ------------------------------------------------------------------------------ > This SF.net Dev2Dev email is sponsored by: > > Show off your parallel programming skills. > Enter the Intel(R) Threading Challenge 2010. > http://p.sf.net/sfu/intel-thread-sfd > _______________________________________________ > sahana-agasti mailing list > sah...@li... > https://lists.sourceforge.net/lists/listinfo/sahana-agasti > -- Greg Miernicki Software Scientist National Library of Medicine 410-696-4623 |
|
From: <Cha...@ma...> - 2010-09-02 18:41:17
|
Hello Community, The SPS team has posted an early draft of our person-management elements of the schema, for the curious. http://wiki.sahanafoundation.org/doku.php/agasti:mayon:schema This is still under heavy development and reflects a number of choices we've been forced to make because of some odd behaviour or limitations within Doctrine but it's there! This is, as the Symfony founder recommends, a 'fat-model' design which should minimize some of the headaches of a future upgrade to 2.0. Also please note that support for scenarios, staff, and clients is still be worked on and has not been intentionally omitted. Ideally, this heavily normalized design should scale forward well into the future and offer plenty of opportunities for plugin and module development. Regards, Chad Heuschober CUNY School of Professional Studies |
|
From: Pearson, G. (NIH/NLM/L. [C] <gpe...@ma...> - 2010-09-02 16:10:05
|
Darlene - Our time is limited to work on this too at the moment... possibly more time towards year end. Please leave the "phase 2" resource up for now. - Glenn ________________________________ From: Dar...@ma... [mailto:Dar...@ma...] Sent: Thursday, September 02, 2010 11:02 AM To: ag...@li... Subject: Re: [sahana-agasti] Wiki Next Steps Hi Glenn et al, I understand that it is not ideal; however I was looking for a lower tech/lower investment solution to a problem that doesn't have an easy answer right now. Unfortunately, we're coming up on the end of our sprint at SPS, and Mayon is requiring more of my attention. I'm not going to have the time to port these over, yet didn't want to leave broken links hanging. While the Phase 2 docs are up on the 'old' wiki it will eventually be brought down and leaning too hard on it now will cause broken links and more work later on. We knew that starting a new instance would cause a few headaches and this appears to be one of them. I realize these docs are important, yet I unfortunately do not have the resources and know-how necessary to bring them over on the back end. Is there someone else in the community that would be willing to focus on Krakatoa's documentation and resolving this issue long-term? For now, the structure of the Agasti wiki is in place and we can begin to flesh it out as a community. I look forward to seeing how it grows as we develop our product. - Darlene McCullough Content Manager; NYC CUNY Sahana Project CUNY School of Professional Studies Dar...@ma... "Pearson, Glenn (NIH/NLM/LHC) [C]" <gpe...@ma...> 09/01/2010 01:18 PM Please respond to ag...@li... To "'ag...@li...'" <ag...@li...> cc Subject Re: [sahana-agasti] Wiki Next Steps Darlene - Here's a significant problem - in the original Dokuwiki form, you could click on an image (which was often too small or blurred to read directly) and get an enlargement. This has been lost in the PDF form. - Glenn ________________________________ From: Dar...@ma... [mailto:Dar...@ma...] Sent: Wednesday, September 01, 2010 12:45 PM To: ag...@li... Cc: 'ag...@li...' Subject: Re: [sahana-agasti] Wiki Next Steps After reading through everyone's thoughts I took a crack at a quick PDF run off of each training & linked them on the wiki here http://wiki.sahanafoundation.org/doku.php/agasti:krakatoa:start I think this will be good for now with more active wiki instruction for Vesuvius & Mayon (it seems that Krakatoa is pretty static at this point). A quick question: the Required Modules table didn't have links & I'm unsure what information goes with these - Greg? There's one missing in the lower table because it was too big to upload; still working on trimming it down. Thanks everyone, Darlene - Darlene McCullough Content Manager; NYC CUNY Sahana Project CUNY School of Professional Studies Dar...@ma... "Pearson, Glenn (NIH/NLM/LHC) [C]" <gpe...@ma...> 09/01/2010 10:41 AM Please respond to ag...@li... To "'ag...@li...'" <ag...@li...> cc Subject Re: [sahana-agasti] Wiki Next Steps FYI. There is circa-2007 standalone software to read in HTML and convert to MediaWiki format (see http://search.cpan.org/~diberri/HTML-WikiConverter-MediaWiki-0.59/ and go up one level for download). But forum posts indicate this doesn't do 100%. -----Original Message----- From: Cha...@ma... [mailto:Cha...@ma...] Sent: Wednesday, September 01, 2010 8:01 AM To: agasti Subject: Re: [sahana-agasti] Wiki Next Steps Gavin, I agree wholeheartedly, however, as you noted, it would be a big undertaking and I don't think I'd be able to volunteer the CUNY team's resources on this. Ideally, someone with some good general scripting skill /should/ be able to write a migration parser but I'm unsure if that's something the community values highly. Regards, Chad Heuschober CUNY School of Professional Studies 101 West 31st Street, 7th Floor New York, NY 10001 cha...@ma... 212.652.2886 ----- Original Message ----- From: Gavin Treadgold [gt...@ke...] Sent: 09/01/2010 10:37 AM ZE12 To: ag...@li... Subject: Re: [sahana-agasti] Wiki Next Steps On 2010-09-01, at 07:47 , Pearson, Glenn (NIH/NLM/LHC) [C] wrote: > Possible someone already familar with the backend dokuwiki could write up some sample commands using mv, rm, etc., that Darlene could then modify. It still would be an awkward process. It's too bad the "pagemove" Dokuwiki plugin is deprecated as too buggy, and no signs of a successor yet. And pagemove didn't move the media either. And this is again why I still keep rooting for Mediawiki and why I refuse to get involved in management of our existing Docuwiki. In a simple wiki, file-based management of pages is fine, but I believe we are starting to run up against management issues in Docuwiki now as we attempt to scale to manage significant amounts of information and support a far wider range of contributors and information managers. Mediawiki OTOH has excellent inbuilt page moving and redirection, and has had for years. Add in the inbuilt categorisation and index pages... and all this is in the base installation with NO additional plugins. Of course, the transition to Mediawiki would also be a massive undertaking. But it sounds like just doing an internal transition is going to be a load of work as well to make Docuwiki do what we want. The requirement to have shell access to manage page moves is unacceptable. Wiki administrators should be able to manage the content in the UI - they need to focus on management of the information, not management of the filesystem. > Sigh. Indeed. Cheers Gav ------------------------------------------------------------------------------ This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd _______________________________________________ sahana-agasti mailing list sah...@li... https://lists.sourceforge.net/lists/listinfo/sahana-agasti ------------------------------------------------------------------------------ This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd _______________________________________________ sahana-agasti mailing list sah...@li... https://lists.sourceforge.net/lists/listinfo/sahana-agasti ------------------------------------------------------------------------------ This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd _______________________________________________ sahana-agasti mailing list sah...@li... https://lists.sourceforge.net/lists/listinfo/sahana-agasti ------------------------------------------------------------------------------ This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd_______________________________________________ sahana-agasti mailing list sah...@li... https://lists.sourceforge.net/lists/listinfo/sahana-agasti |
|
From: <Dar...@ma...> - 2010-09-02 15:02:15
|
Hi Glenn et al, I understand that it is not ideal; however I was looking for a lower tech/lower investment solution to a problem that doesn't have an easy answer right now. Unfortunately, we're coming up on the end of our sprint at SPS, and Mayon is requiring more of my attention. I'm not going to have the time to port these over, yet didn't want to leave broken links hanging. While the Phase 2 docs are up on the 'old' wiki it will eventually be brought down and leaning too hard on it now will cause broken links and more work later on. We knew that starting a new instance would cause a few headaches and this appears to be one of them. I realize these docs are important, yet I unfortunately do not have the resources and know-how necessary to bring them over on the back end. Is there someone else in the community that would be willing to focus on Krakatoa's documentation and resolving this issue long-term? For now, the structure of the Agasti wiki is in place and we can begin to flesh it out as a community. I look forward to seeing how it grows as we develop our product. - Darlene McCullough Content Manager; NYC CUNY Sahana Project CUNY School of Professional Studies Dar...@ma... "Pearson, Glenn (NIH/NLM/LHC) [C]" <gpe...@ma...> 09/01/2010 01:18 PM Please respond to ag...@li... To "'ag...@li...'" <ag...@li...> cc Subject Re: [sahana-agasti] Wiki Next Steps Darlene - Here's a significant problem - in the original Dokuwiki form, you could click on an image (which was often too small or blurred to read directly) and get an enlargement. This has been lost in the PDF form. - Glenn From: Dar...@ma... [ mailto:Dar...@ma...] Sent: Wednesday, September 01, 2010 12:45 PM To: ag...@li... Cc: 'ag...@li...' Subject: Re: [sahana-agasti] Wiki Next Steps After reading through everyone's thoughts I took a crack at a quick PDF run off of each training & linked them on the wiki here http://wiki.sahanafoundation.org/doku.php/agasti:krakatoa:start I think this will be good for now with more active wiki instruction for Vesuvius & Mayon (it seems that Krakatoa is pretty static at this point). A quick question: the Required Modules table didn't have links & I'm unsure what information goes with these - Greg? There's one missing in the lower table because it was too big to upload; still working on trimming it down. Thanks everyone, Darlene - Darlene McCullough Content Manager; NYC CUNY Sahana Project CUNY School of Professional Studies Dar...@ma... "Pearson, Glenn (NIH/NLM/LHC) [C]" <gpe...@ma...> 09/01/2010 10:41 AM Please respond to ag...@li... To "'ag...@li...'" <ag...@li...> cc Subject Re: [sahana-agasti] Wiki Next Steps FYI. There is circa-2007 standalone software to read in HTML and convert to MediaWiki format (see http://search.cpan.org/~diberri/HTML-WikiConverter-MediaWiki-0.59/ and go up one level for download). But forum posts indicate this doesn't do 100%. -----Original Message----- From: Cha...@ma... [mailto:Cha...@ma...] Sent: Wednesday, September 01, 2010 8:01 AM To: agasti Subject: Re: [sahana-agasti] Wiki Next Steps Gavin, I agree wholeheartedly, however, as you noted, it would be a big undertaking and I don't think I'd be able to volunteer the CUNY team's resources on this. Ideally, someone with some good general scripting skill /should/ be able to write a migration parser but I'm unsure if that's something the community values highly. Regards, Chad Heuschober CUNY School of Professional Studies 101 West 31st Street, 7th Floor New York, NY 10001 cha...@ma... 212.652.2886 ----- Original Message ----- From: Gavin Treadgold [gt...@ke...] Sent: 09/01/2010 10:37 AM ZE12 To: ag...@li... Subject: Re: [sahana-agasti] Wiki Next Steps On 2010-09-01, at 07:47 , Pearson, Glenn (NIH/NLM/LHC) [C] wrote: > Possible someone already familar with the backend dokuwiki could write up some sample commands using mv, rm, etc., that Darlene could then modify. It still would be an awkward process. It's too bad the "pagemove" Dokuwiki plugin is deprecated as too buggy, and no signs of a successor yet. And pagemove didn't move the media either. And this is again why I still keep rooting for Mediawiki and why I refuse to get involved in management of our existing Docuwiki. In a simple wiki, file-based management of pages is fine, but I believe we are starting to run up against management issues in Docuwiki now as we attempt to scale to manage significant amounts of information and support a far wider range of contributors and information managers. Mediawiki OTOH has excellent inbuilt page moving and redirection, and has had for years. Add in the inbuilt categorisation and index pages... and all this is in the base installation with NO additional plugins. Of course, the transition to Mediawiki would also be a massive undertaking. But it sounds like just doing an internal transition is going to be a load of work as well to make Docuwiki do what we want. The requirement to have shell access to manage page moves is unacceptable. Wiki administrators should be able to manage the content in the UI - they need to focus on management of the information, not management of the filesystem. > Sigh. Indeed. Cheers Gav ------------------------------------------------------------------------------ This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd _______________________________________________ sahana-agasti mailing list sah...@li... https://lists.sourceforge.net/lists/listinfo/sahana-agasti ------------------------------------------------------------------------------ This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd _______________________________________________ sahana-agasti mailing list sah...@li... https://lists.sourceforge.net/lists/listinfo/sahana-agasti ------------------------------------------------------------------------------ This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd _______________________________________________ sahana-agasti mailing list sah...@li... https://lists.sourceforge.net/lists/listinfo/sahana-agasti ------------------------------------------------------------------------------ This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd _______________________________________________ sahana-agasti mailing list sah...@li... https://lists.sourceforge.net/lists/listinfo/sahana-agasti |
|
From: Pearson, G. (NIH/NLM/L. [C] <gpe...@ma...> - 2010-09-01 17:18:45
|
Darlene - Here's a significant problem - in the original Dokuwiki form, you could click on an image (which was often too small or blurred to read directly) and get an enlargement. This has been lost in the PDF form. - Glenn ________________________________ From: Dar...@ma... [mailto:Dar...@ma...] Sent: Wednesday, September 01, 2010 12:45 PM To: ag...@li... Cc: 'ag...@li...' Subject: Re: [sahana-agasti] Wiki Next Steps After reading through everyone's thoughts I took a crack at a quick PDF run off of each training & linked them on the wiki here http://wiki.sahanafoundation.org/doku.php/agasti:krakatoa:start I think this will be good for now with more active wiki instruction for Vesuvius & Mayon (it seems that Krakatoa is pretty static at this point). A quick question: the Required Modules table didn't have links & I'm unsure what information goes with these - Greg? There's one missing in the lower table because it was too big to upload; still working on trimming it down. Thanks everyone, Darlene - Darlene McCullough Content Manager; NYC CUNY Sahana Project CUNY School of Professional Studies Dar...@ma... "Pearson, Glenn (NIH/NLM/LHC) [C]" <gpe...@ma...> 09/01/2010 10:41 AM Please respond to ag...@li... To "'ag...@li...'" <ag...@li...> cc Subject Re: [sahana-agasti] Wiki Next Steps FYI. There is circa-2007 standalone software to read in HTML and convert to MediaWiki format (see http://search.cpan.org/~diberri/HTML-WikiConverter-MediaWiki-0.59/ and go up one level for download). But forum posts indicate this doesn't do 100%. -----Original Message----- From: Cha...@ma... [mailto:Cha...@ma...] Sent: Wednesday, September 01, 2010 8:01 AM To: agasti Subject: Re: [sahana-agasti] Wiki Next Steps Gavin, I agree wholeheartedly, however, as you noted, it would be a big undertaking and I don't think I'd be able to volunteer the CUNY team's resources on this. Ideally, someone with some good general scripting skill /should/ be able to write a migration parser but I'm unsure if that's something the community values highly. Regards, Chad Heuschober CUNY School of Professional Studies 101 West 31st Street, 7th Floor New York, NY 10001 cha...@ma... 212.652.2886 ----- Original Message ----- From: Gavin Treadgold [gt...@ke...] Sent: 09/01/2010 10:37 AM ZE12 To: ag...@li... Subject: Re: [sahana-agasti] Wiki Next Steps On 2010-09-01, at 07:47 , Pearson, Glenn (NIH/NLM/LHC) [C] wrote: > Possible someone already familar with the backend dokuwiki could write up some sample commands using mv, rm, etc., that Darlene could then modify. It still would be an awkward process. It's too bad the "pagemove" Dokuwiki plugin is deprecated as too buggy, and no signs of a successor yet. And pagemove didn't move the media either. And this is again why I still keep rooting for Mediawiki and why I refuse to get involved in management of our existing Docuwiki. In a simple wiki, file-based management of pages is fine, but I believe we are starting to run up against management issues in Docuwiki now as we attempt to scale to manage significant amounts of information and support a far wider range of contributors and information managers. Mediawiki OTOH has excellent inbuilt page moving and redirection, and has had for years. Add in the inbuilt categorisation and index pages... and all this is in the base installation with NO additional plugins. Of course, the transition to Mediawiki would also be a massive undertaking. But it sounds like just doing an internal transition is going to be a load of work as well to make Docuwiki do what we want. The requirement to have shell access to manage page moves is unacceptable. Wiki administrators should be able to manage the content in the UI - they need to focus on management of the information, not management of the filesystem. > Sigh. Indeed. Cheers Gav ------------------------------------------------------------------------------ This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd _______________________________________________ sahana-agasti mailing list sah...@li... https://lists.sourceforge.net/lists/listinfo/sahana-agasti ------------------------------------------------------------------------------ This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd _______________________________________________ sahana-agasti mailing list sah...@li... https://lists.sourceforge.net/lists/listinfo/sahana-agasti ------------------------------------------------------------------------------ This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd _______________________________________________ sahana-agasti mailing list sah...@li... https://lists.sourceforge.net/lists/listinfo/sahana-agasti |
|
From: <Dar...@ma...> - 2010-09-01 16:45:18
|
After reading through everyone's thoughts I took a crack at a quick PDF run off of each training & linked them on the wiki here http://wiki.sahanafoundation.org/doku.php/agasti:krakatoa:start I think this will be good for now with more active wiki instruction for Vesuvius & Mayon (it seems that Krakatoa is pretty static at this point). A quick question: the Required Modules table didn't have links & I'm unsure what information goes with these - Greg? There's one missing in the lower table because it was too big to upload; still working on trimming it down. Thanks everyone, Darlene - Darlene McCullough Content Manager; NYC CUNY Sahana Project CUNY School of Professional Studies Dar...@ma... "Pearson, Glenn (NIH/NLM/LHC) [C]" <gpe...@ma...> 09/01/2010 10:41 AM Please respond to ag...@li... To "'ag...@li...'" <ag...@li...> cc Subject Re: [sahana-agasti] Wiki Next Steps FYI. There is circa-2007 standalone software to read in HTML and convert to MediaWiki format (see http://search.cpan.org/~diberri/HTML-WikiConverter-MediaWiki-0.59/ and go up one level for download). But forum posts indicate this doesn't do 100%. -----Original Message----- From: Cha...@ma... [mailto:Cha...@ma...] Sent: Wednesday, September 01, 2010 8:01 AM To: agasti Subject: Re: [sahana-agasti] Wiki Next Steps Gavin, I agree wholeheartedly, however, as you noted, it would be a big undertaking and I don't think I'd be able to volunteer the CUNY team's resources on this. Ideally, someone with some good general scripting skill /should/ be able to write a migration parser but I'm unsure if that's something the community values highly. Regards, Chad Heuschober CUNY School of Professional Studies 101 West 31st Street, 7th Floor New York, NY 10001 cha...@ma... 212.652.2886 ----- Original Message ----- From: Gavin Treadgold [gt...@ke...] Sent: 09/01/2010 10:37 AM ZE12 To: ag...@li... Subject: Re: [sahana-agasti] Wiki Next Steps On 2010-09-01, at 07:47 , Pearson, Glenn (NIH/NLM/LHC) [C] wrote: > Possible someone already familar with the backend dokuwiki could write up some sample commands using mv, rm, etc., that Darlene could then modify. It still would be an awkward process. It's too bad the "pagemove" Dokuwiki plugin is deprecated as too buggy, and no signs of a successor yet. And pagemove didn't move the media either. And this is again why I still keep rooting for Mediawiki and why I refuse to get involved in management of our existing Docuwiki. In a simple wiki, file-based management of pages is fine, but I believe we are starting to run up against management issues in Docuwiki now as we attempt to scale to manage significant amounts of information and support a far wider range of contributors and information managers. Mediawiki OTOH has excellent inbuilt page moving and redirection, and has had for years. Add in the inbuilt categorisation and index pages... and all this is in the base installation with NO additional plugins. Of course, the transition to Mediawiki would also be a massive undertaking. But it sounds like just doing an internal transition is going to be a load of work as well to make Docuwiki do what we want. The requirement to have shell access to manage page moves is unacceptable. Wiki administrators should be able to manage the content in the UI - they need to focus on management of the information, not management of the filesystem. > Sigh. Indeed. Cheers Gav ------------------------------------------------------------------------------ This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd _______________________________________________ sahana-agasti mailing list sah...@li... https://lists.sourceforge.net/lists/listinfo/sahana-agasti ------------------------------------------------------------------------------ This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd _______________________________________________ sahana-agasti mailing list sah...@li... https://lists.sourceforge.net/lists/listinfo/sahana-agasti ------------------------------------------------------------------------------ This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd _______________________________________________ sahana-agasti mailing list sah...@li... https://lists.sourceforge.net/lists/listinfo/sahana-agasti |
|
From: Pearson, G. (NIH/NLM/L. [C] <gpe...@ma...> - 2010-09-01 14:41:12
|
FYI. There is circa-2007 standalone software to read in HTML and convert to MediaWiki format (see http://search.cpan.org/~diberri/HTML-WikiConverter-MediaWiki-0.59/ and go up one level for download). But forum posts indicate this doesn't do 100%. -----Original Message----- From: Cha...@ma... [mailto:Cha...@ma...] Sent: Wednesday, September 01, 2010 8:01 AM To: agasti Subject: Re: [sahana-agasti] Wiki Next Steps Gavin, I agree wholeheartedly, however, as you noted, it would be a big undertaking and I don't think I'd be able to volunteer the CUNY team's resources on this. Ideally, someone with some good general scripting skill /should/ be able to write a migration parser but I'm unsure if that's something the community values highly. Regards, Chad Heuschober CUNY School of Professional Studies 101 West 31st Street, 7th Floor New York, NY 10001 cha...@ma... 212.652.2886 ----- Original Message ----- From: Gavin Treadgold [gt...@ke...] Sent: 09/01/2010 10:37 AM ZE12 To: ag...@li... Subject: Re: [sahana-agasti] Wiki Next Steps On 2010-09-01, at 07:47 , Pearson, Glenn (NIH/NLM/LHC) [C] wrote: > Possible someone already familar with the backend dokuwiki could write up some sample commands using mv, rm, etc., that Darlene could then modify. It still would be an awkward process. It's too bad the "pagemove" Dokuwiki plugin is deprecated as too buggy, and no signs of a successor yet. And pagemove didn't move the media either. And this is again why I still keep rooting for Mediawiki and why I refuse to get involved in management of our existing Docuwiki. In a simple wiki, file-based management of pages is fine, but I believe we are starting to run up against management issues in Docuwiki now as we attempt to scale to manage significant amounts of information and support a far wider range of contributors and information managers. Mediawiki OTOH has excellent inbuilt page moving and redirection, and has had for years. Add in the inbuilt categorisation and index pages... and all this is in the base installation with NO additional plugins. Of course, the transition to Mediawiki would also be a massive undertaking. But it sounds like just doing an internal transition is going to be a load of work as well to make Docuwiki do what we want. The requirement to have shell access to manage page moves is unacceptable. Wiki administrators should be able to manage the content in the UI - they need to focus on management of the information, not management of the filesystem. > Sigh. Indeed. Cheers Gav ------------------------------------------------------------------------------ This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd _______________________________________________ sahana-agasti mailing list sah...@li... https://lists.sourceforge.net/lists/listinfo/sahana-agasti ------------------------------------------------------------------------------ This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd _______________________________________________ sahana-agasti mailing list sah...@li... https://lists.sourceforge.net/lists/listinfo/sahana-agasti |
|
From: <Cha...@ma...> - 2010-09-01 12:01:27
|
Gavin, I agree wholeheartedly, however, as you noted, it would be a big undertaking and I don't think I'd be able to volunteer the CUNY team's resources on this. Ideally, someone with some good general scripting skill /should/ be able to write a migration parser but I'm unsure if that's something the community values highly. Regards, Chad Heuschober CUNY School of Professional Studies 101 West 31st Street, 7th Floor New York, NY 10001 cha...@ma... 212.652.2886 ----- Original Message ----- From: Gavin Treadgold [gt...@ke...] Sent: 09/01/2010 10:37 AM ZE12 To: ag...@li... Subject: Re: [sahana-agasti] Wiki Next Steps On 2010-09-01, at 07:47 , Pearson, Glenn (NIH/NLM/LHC) [C] wrote: > Possible someone already familar with the backend dokuwiki could write up some sample commands using mv, rm, etc., that Darlene could then modify. It still would be an awkward process. It's too bad the "pagemove" Dokuwiki plugin is deprecated as too buggy, and no signs of a successor yet. And pagemove didn't move the media either. And this is again why I still keep rooting for Mediawiki and why I refuse to get involved in management of our existing Docuwiki. In a simple wiki, file-based management of pages is fine, but I believe we are starting to run up against management issues in Docuwiki now as we attempt to scale to manage significant amounts of information and support a far wider range of contributors and information managers. Mediawiki OTOH has excellent inbuilt page moving and redirection, and has had for years. Add in the inbuilt categorisation and index pages... and all this is in the base installation with NO additional plugins. Of course, the transition to Mediawiki would also be a massive undertaking. But it sounds like just doing an internal transition is going to be a load of work as well to make Docuwiki do what we want. The requirement to have shell access to manage page moves is unacceptable. Wiki administrators should be able to manage the content in the UI - they need to focus on management of the information, not management of the filesystem. > Sigh. Indeed. Cheers Gav ------------------------------------------------------------------------------ This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd _______________________________________________ sahana-agasti mailing list sah...@li... https://lists.sourceforge.net/lists/listinfo/sahana-agasti |
|
From: <Cha...@ma...> - 2010-09-01 00:59:02
|
Usman, Let's discuss, after this sprint concludes next wednesday, adapting a few pieces from our team's test strategy to add to the wiki. The parts that describe types of tests and the timing / responsibility matrices come to mind. Regards, Chad Heuschober CUNY School of Professional Studies 101 West 31st Street, 7th Floor New York, NY 10001 cha...@ma... 212.652.2886 ----- Original Message ----- From: Gavin Treadgold [gt...@ke...] Sent: 09/01/2010 11:45 AM ZE12 To: ag...@li... Subject: Re: [sahana-agasti] Demo and Test Management Yep - makes perfect sense. Just as long as we are clear about the different types of testing that are relevant. It would be good to break this down in the wiki at some stage. We do need to be clear about the names of the different forms of testing used across multiple projects, as it may be a valid comparison at some point to compare the different (or similar) approaches to testing used not only on different Agasti series, but also with Eden. Cheers Gav On 2010-09-01, at 05:38 , Usm...@ma... wrote: > I think the short answer to both questions is "yes." :] > > Functional tests can be written and implemented straight from the requirements. They should fail first (since there'd be nothing testable implemented yet), and pass only after a requirement is complete & correct. Of course, functional and unit tests would need to be refactored some as application code is developed and refined. The "standard development environment" and recommended tools, test+dev workflow, and code submission process should at some point be decided, but that's probably best suited for another thread. > > Regarding different forms of tests, there will likely be some form of UAT, performance testing (load & stress), and other testing that devs and testers should not be expected or required to perform in their local environment. This kind of testing is more likely to require dedicated, non-public Agasti server(s)/VM(s), as I suggested. Does this make sense? > > Cheers, > -- > Usman Akeju > Software Quality Assurance Engineer, Sahana Agasti Team > CUNY School of Professional Studies > tel: 212.652.2098 > > > Gavin Treadgold <gt...@ke...> wrote on 08/30/2010 10:50:34 PM: > > > > A quick question from me on testing - I got the impression that > > Mayon will heavily rely on test-driven development, so won't that > > mean that the testing should actually be significantly integrated > > into the developer environment? Or are we looking at different formsof tests? > > > > Cheers Gav ------------------------------------------------------------------------------ This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd _______________________________________________ sahana-agasti mailing list sah...@li... https://lists.sourceforge.net/lists/listinfo/sahana-agasti |
|
From: Gavin T. <gt...@ke...> - 2010-08-31 23:46:04
|
Yep - makes perfect sense. Just as long as we are clear about the different types of testing that are relevant. It would be good to break this down in the wiki at some stage. We do need to be clear about the names of the different forms of testing used across multiple projects, as it may be a valid comparison at some point to compare the different (or similar) approaches to testing used not only on different Agasti series, but also with Eden. Cheers Gav On 2010-09-01, at 05:38 , Usm...@ma... wrote: > I think the short answer to both questions is "yes." :] > > Functional tests can be written and implemented straight from the requirements. They should fail first (since there'd be nothing testable implemented yet), and pass only after a requirement is complete & correct. Of course, functional and unit tests would need to be refactored some as application code is developed and refined. The "standard development environment" and recommended tools, test+dev workflow, and code submission process should at some point be decided, but that's probably best suited for another thread. > > Regarding different forms of tests, there will likely be some form of UAT, performance testing (load & stress), and other testing that devs and testers should not be expected or required to perform in their local environment. This kind of testing is more likely to require dedicated, non-public Agasti server(s)/VM(s), as I suggested. Does this make sense? > > Cheers, > -- > Usman Akeju > Software Quality Assurance Engineer, Sahana Agasti Team > CUNY School of Professional Studies > tel: 212.652.2098 > > > Gavin Treadgold <gt...@ke...> wrote on 08/30/2010 10:50:34 PM: > > > > A quick question from me on testing - I got the impression that > > Mayon will heavily rely on test-driven development, so won't that > > mean that the testing should actually be significantly integrated > > into the developer environment? Or are we looking at different formsof tests? > > > > Cheers Gav |
25 messages has been excluded from this view by a project administrator.