dithaka-devel Mailing List for Dithaka

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Hello Dithaka https://bit.ly/2qnDgNy     
hi Dithaka

http://icta.ubhara.ac.id/wp-content/uploads/2017/07/abonnement.php?largest=2y70mbk5akskdtxy4

Good day.

As some of you know I worked on these projects:

Coefficient (https://sourceforge.net/ projects/coefficient/) and Dithaka (https://sourceforge.net/ projects/dithaka/) projects in 2005/2006 :)

I was working at the CSIR (Division: Meraka) which created Coefficient and its associated project Dithaka:

I was not the original architect of these projects.

We tried to
 revive these projects since 2006-2010 when I was working at the CSIR and 
taking more ownership. The revival never took off. 

This project was used mostly at the University Of Pretoria. Morkel Theunissen (my friend and lecturer at UP) mostly promoted this project and asked that all 
third years students use Coefficient to manage their projects. I think 
they used Coefficient till about 2010. They also wrote some integration 
plugins with SVN.

I and some friends would like to take these projects over and implement some of my research ideas.

Some of technology plans will be:

	*     Use JPA+JSF
	*     Decide on EJB3 or Spring to provide services.
	*     Rewite all UI's
	*     Use Richfaces or Primefaces and their mobile frameworks
	*     Make the site mobile friendly
	*     Investigate the use of No-Sql (MongoDB, Oracle Berkley DB,etc) or object databases or use my own no-sql object database     

Other ideas:
	* Project management tools
	* Review tools
	* Data science
	* Deploy to Cloud
	* Log analysis
	* Forum chat analysis

We could fork these projects but I feel I do have a history with them and they are not currently maintained.

Plus forking of a project is not a great thing to do. Splits the effort and confuses users.

The Cathedral and the Bazaar states that:
"5. When you lose interest in a program, your last duty to it is to hand it off to a
competent successor."

Ending an Open-Source Project:
"It is natural for the founder of an open-source project to leave in 
order to move on to other interests. However, this does not necessarily 
mean just abandoning the project."
http://dreamsongs.com/ihe/IHE- 56.html

I also know that Meraka always wanted people to take their ideas further and make a success in the outside world.

Can I please take over these projects? Credit will be given to the original teams.

Can we agree that I can take over these projects if I hear no objections in the next month?

Also note that both projects are using LGPL licenses.

The Coeficient license states:

/*
 * Coefficient - facilitates project based collaboration
 * Copyright (C) 2003, Dylan Etkin, CSIR icomtek
 * PO Box 395
 * Pretoria 0001, RSA
 * This library is free software; you can redistribute it and/or
 * modify it under the terms of the GNU Lesser General Public
 * License as published by the Free Software Foundation; either
 * version 2.1 of the License, or (at your option) any later version.
 * This library is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
 * Lesser General Public License for more details.
 *
 * You should have received a copy of the GNU Lesser General Public
 * License along with this library; if not, write to the Free Software
 * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
 */

I have also tried to follow some of these suggestions:

http://programmers. stackexchange.com/questions/ 125789/how-to-go-about-taking- over-an-open-source-project

If there are any other suggestions or concerns please mail me.

Please also forward this mail to anyone that you feel might have an interest in this project.

Kindly
Pieter van Zyl
Things I want to add to the todo list.

1. Update tapestry to ver.4.x
2. Look at available components (tacos components look good
http://tacos.sourceforge.net/), maybe rich text editor and ajax
components to enhance look and usebility.
3. Look at new JDO and to have more options for persistance. (Whould
like to have db4o available)
4. Look at a simpler way to access dithaka from other project (To
address the resource concerns).

Andries

-- 
This message is subject to the CSIR's copyright, terms and conditions and
e-mail legal notice. Views expressed herein do not necessarily represent the
views of the CSIR.

CSIR E-mail Legal Notice
http://mail.csir.co.za/CSIR_eMail_Legal_Notice.html 

CSIR Copyright, Terms and Conditions
http://mail.csir.co.za/CSIR_Copyright.html 

For electronic copies of the CSIR Copyright, Terms and Conditions and the CSIR
Legal Notice send a blank message with REQUEST LEGAL in the subject line to
Cal...@cs....

This message has been scanned for viruses and dangerous content by MailScanner, 
and is believed to be clean.  MailScanner thanks Transtec Computers for their support.

Hi

On Fri, 2006-11-24 at 09:20 +0200, pieter van zyl wrote:
> > I have various thoughts, I guess.  I think simplifying the discussion
> > stuff would probably be useful, so yup it's likely that doesn't need
> > resources.  I think the resource stuff does have some benefit - so the
> > choice would be 1) either lose the benefit or 2) try get the benefit
> > with some other mechanism, like tagging.  And again, the original
> > thinking was to add collaboration to a project with hopefully minimal
> > effect on existing classes.  Must be many ways to do that.  
> Yes, in the end I see dithaka as a library with an API that can be used
> by a project to add collaboration. 
>
> I just feel(I might be wrong) with RDF it is tightly coupled and the
> project using the resource and RDF concept(dithaka) needs to be aware of
> this.

In my view, using the RDF concepts makes the coupling looser, and more
dynamic. It does add some complexity, perhaps, because there is an extra
level of indirection, but this is unavoidable in a metadata framework.
In my view, a metadata framework is the only way to allow easy
"retrofitting" of Dithaka collaboration features into an existing
codebase. Does this mean that Dithaka should continue to use the
Reosurce concept internally? Not necessarily. I'm not against
simplifying the internals of Dithaka, but there are some things we could
potentially lose. e.g. with the Resource stuff, a message can be in
response to another (predicate = reply), but it could also be tagged as
referring to a point in a completely separate message (predicate =
refer), as contradicting another message (predicate = contradict), etc.
There is simply no way that we can statically determine all these
relationships. Granted, we don't use any of these relationships
currently, but the possibility is there for us to do so, and would be
lost if we adopted a more static structure. I'm not saying that we
should not simplify things, only that we need to consider the
consequences.

If we do make the internal model more static, we need to do so very
carefully, because by doing so we're effectively splitting our current
model (currently the internal model is the same as the external/api
one). We'll then be using the more static internal model for
collaboration features that we provide in Dithaka as standard (e.g.
forums, mailing lists), but we'll be using the metadata framework for
any additional collaboration features that people may need, and as the
integration layer to existing code.

An alternative could be to keep using the resource stuff internally, but
to create simple wrappers that hide the internal RDF structures,
exposing only the more static relationships and behaving the way one
would expect normal forum objects to behave. Thoughts?

> Also, talking to Andries it seems our description of dithaka might be
> incorrect? 
> 
> Are people downloading and using dithaka as a forum api or are they
> actively using the resource concept to link complex data?

Yes, the description is not 100% complete, as it does not mention the
RDF stuff at all. Is the following better?
"Dithaka is a dynamic collaboration framework written in Java. It uses
RDF-inspired subject-predicate-object relationships to relate objects to
one another in a flexible way. This allows the framework to create
arbitrary relationships between collaboration objects.

Using the same metadata model, Dithaka can also be used to add
collaboration features to existing (or new) projects in an unobtrusive
way, by linking objects in the existing data model to the collaboration
objects provided by Dithaka.

Dithaka ships with integrated mailing list and web discussion forum
modules; every message sent to the list appears as a post in the forum,
and every post to the forum generates a message to the list."

m2c
-- 
Thomas Fogwill <tfo...@us...>

On Thu, 2006-11-23 at 13:17 +0200, Richard Watson wrote:
> Hi Pieter,
>=20
> Do you mean remove altogether or remove from the discussion part?
> Sounds like remove altogether, so I'll respond with that assumption :)
Yes.........and I am just throwing it out here to get an better idea on
why we use it and how it should be used...........=20
>=20
> I have various thoughts, I guess.  I think simplifying the discussion
> stuff would probably be useful, so yup it's likely that doesn't need
> resources.  I think the resource stuff does have some benefit - so the
> choice would be 1) either lose the benefit or 2) try get the benefit
> with some other mechanism, like tagging.  And again, the original
> thinking was to add collaboration to a project with hopefully minimal
> effect on existing classes.  Must be many ways to do that.=20=20
Yes, in the end I see dithaka as a library with an API that can be used
by a project to add collaboration.=20

I just feel(I might be wrong) with RDF it is tightly coupled and the
project using the resource and RDF concept(dithaka) needs to be aware of
this.

I feel RDF could be used to associate data that does not have a direct
association with each other. Looking at a forum with a conversation I
feel there is a direct association and it is internal to Dithaka.

I feel it also not so easy to add these Resources. It is not so easy to
associate a Coefficient Project with a Forum in Dithaka. Is there
another way? Maybe the resource way is the only way when
"integrating/linking"=20

Maybe I can try and change it on our new project and see if there is a
different solution.=20

> If that's
> not important, then why not just use any other discussion forum
> software?  You could also just start another project, strip out the
> useful discussion stuff and lose the resources that way, or add it
> directly to coefficient if that's where you need it.
I was thinking of using it on a project and stripping away the
resources. And see what happens.
>=20
> In any case, I have mostly a legacy interest in it and you guys are
> core to it now so if it's causing you pain then you need a solution.
>=20

Also, talking to Andries it seems our description of dithaka might be
incorrect?=20

Are people downloading and using dithaka as a forum api or are they
actively using the resource concept to link complex data?
> Thoughts?
> Richard
>=20
> On 11/23/06, pieter van zyl <pv...@cs...> wrote:
> > Good day,
> >
> > Looks like the project has had consistent downloads throughout the
> > year :)
> >
> > I would like to start a discussion about RDF concept.
> >
> > I would like to remove the Resource idea. I feel it is great to have
> > metadata and all that but it is overkill for our forum classes: Message,
> > Forum, Conversation etc.
> >
> > The resource idea is also not intuitive for when you are debugging
> > Dithaka..........
> >
> > Anyone with comments?
> >
> > Pieter
> >
> >
> > -----------------------------------------------------------------------=
--
> > 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=3Djoin.php&p=3Dsourceforge&CID=
=3DDEVDEV
> >
> > _______________________________________________
> > Dithaka-devel mailing list
> > Dit...@li...
> > https://lists.sourceforge.net/lists/listinfo/dithaka-devel
> >
> >
> >
> >
>=20
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share y=
our
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D=
DEVDEV
> _______________________________________________
> Dithaka-devel mailing list
> Dit...@li...
> https://lists.sourceforge.net/lists/listinfo/dithaka-devel

Hi Pieter,

Do you mean remove altogether or remove from the discussion part?
Sounds like remove altogether, so I'll respond with that assumption :)

I have various thoughts, I guess.  I think simplifying the discussion
stuff would probably be useful, so yup it's likely that doesn't need
resources.  I think the resource stuff does have some benefit - so the
choice would be 1) either lose the benefit or 2) try get the benefit
with some other mechanism, like tagging.  And again, the original
thinking was to add collaboration to a project with hopefully minimal
effect on existing classes.  Must be many ways to do that.  If that's
not important, then why not just use any other discussion forum
software?  You could also just start another project, strip out the
useful discussion stuff and lose the resources that way, or add it
directly to coefficient if that's where you need it.

In any case, I have mostly a legacy interest in it and you guys are
core to it now so if it's causing you pain then you need a solution.

Thoughts?
Richard

On 11/23/06, pieter van zyl <pv...@cs...> wrote:
> Good day,
>
> Looks like the project has had consistent downloads throughout the
> year :)
>
> I would like to start a discussion about RDF concept.
>
> I would like to remove the Resource idea. I feel it is great to have
> metadata and all that but it is overkill for our forum classes: Message,
> Forum, Conversation etc.
>
> The resource idea is also not intuitive for when you are debugging
> Dithaka..........
>
> Anyone with comments?
>
> Pieter
>
>
> -------------------------------------------------------------------------
> 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
>
> _______________________________________________
> Dithaka-devel mailing list
> Dit...@li...
> https://lists.sourceforge.net/lists/listinfo/dithaka-devel
>
>
>
>

Good day,

Looks like the project has had consistent downloads throughout the
year :)

I would like to start a discussion about RDF concept.

I would like to remove the Resource idea. I feel it is great to have
metadata and all that but it is overkill for our forum classes: Message,
Forum, Conversation etc.

The resource idea is also not intuitive for when you are debugging
Dithaka..........

Anyone with comments?=20

Pieter

Jason,

I have corrected this issue.=20

Whenever we do the select and comparison on the e-mail and forum address
we lower the values and now it should be case insensitive.

Please check out the latest Dithaka-Base and Dithaka-James code and
deploy it to your James server.=20

You can also rebuild your mailforum module just to make sure it uses the
newest dithaka libraries.

Let me know if this works.

On Wed, 2005-11-09 at 16:02 +0000, Jason Meyler wrote:
> Hi Pieter,
>=20
> Have been running some quick tests as some users have experienced=20
> sending emails which have not arrived at the forum they were sent to.
>=20
> I have discovered the following:
>=20
> - a mail addressed to Tes...@op... arrives in the=20
> forum and is sent to forum members.
>=20
> - a mail addressed to tes...@op... is sent to the=20
> James address-error folder on the server and is not sent any further.
>=20
> Can you confirm that mail forum email addresses are in fact case=20
> sensitive. Shouldn't this be corrected to make them case insensitive?
> What do you think?
>=20
> Best regards
>=20
> Jason
>=20
>=20
> -------------------------------------------------------
> SF.Net email is sponsored by:
> Tame your development challenges with Apache's Geronimo App Server. Downl=
oad
> it for free - -and be entered to win a 42" plasma tv or your very own
> Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
> _______________________________________________
> Coefficient-users mailing list
> Coe...@li...
> https://lists.sourceforge.net/lists/listinfo/coefficient-users
--=20
Pieter van Zyl
Java Developer
Meraka Institute

Phone: 012 841 2484

Brian,

We are fixing some of the Tapestry front-end pages and will put it into
cvs in 2/3 weeks time.

Have you tried the Coefficient yet?

Pieter

-- 
This message is subject to the CSIR's copyright, terms and conditions and
e-mail legal notice. Views expressed herein do not necessarily represent the
views of the CSIR.

CSIR E-mail Legal Notice
http://mail.csir.co.za/CSIR_eMail_Legal_Notice.html 

CSIR Copyright, Terms and Conditions
http://mail.csir.co.za/CSIR_Copyright.html 

For electronic copies of the CSIR Copyright, Terms and Conditions and the CSIR
Legal Notice send a blank message with REQUEST LEGAL in the subject line to
Hel...@cs....

This message has been scanned for viruses and dangerous content by MailScanner, 
and is believed to be clean.  MailScanner thanks Transtec Computers for their support.

On Thu, 2005-09-08 at 14:10 -0700, Brian Guan wrote:
> Just trying to evaluate Dithaka.
> 
> I checked out from CVS and realized most of the jars are
> checked in as ASCII instead of binary.
> 
> Just though you might want to fix it.

Thanks for the heads up. I'll take a look at it ASAP.

-- 
Thomas Fogwill <tfo...@us...>

-- 
This message is subject to the CSIR's copyright, terms and conditions and
e-mail legal notice. Views expressed herein do not necessarily represent the
views of the CSIR.

CSIR E-mail Legal Notice
http://mail.csir.co.za/CSIR_eMail_Legal_Notice.html 

CSIR Copyright, Terms and Conditions
http://mail.csir.co.za/CSIR_Copyright.html 

For electronic copies of the CSIR Copyright, Terms and Conditions and the CSIR
Legal Notice send a blank message with REQUEST LEGAL in the subject line to
Hel...@cs....

This message has been scanned for viruses and dangerous content by MailScanner, 
and is believed to be clean.  MailScanner thanks Transtec Computers for their support.

I've created a new mailing lists to receive CVS commit notifications.
Subscribe to this list if you're keen to track CVS activity. 

The list is called dithaka-commits and can be found here:
http://sourceforge.net/mail/?group_id=139779

Regards
T

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
MailScanner thanks transtec Computers for their support.

For the moment yes.

Your current and new users emails should still work! They will just
display either the new or old domain. 

I have a dithaka_alias_user table which contains:
aliasId,aliasmailAddress,realMailAddress and userName

We add an entry here for each user, and Dithaka uses this table to map
from the alias address used in the system to the real email address to
send out. It displays the alias thought in the headers.

Solutions: add a library to do this and an admin page, add sql scripts
or remove the alias domain name from the alias entries
in Dithaka and concat the username+alias_domain each time it is needed. 

This info will be on the page below tomorrow:
http://coefficient.sourceforge.net/modules/mailforum.html

Also another issue: If the real address of the users changes the
mailforum needs to be notified so that it can update the
dithaka_alias_user. This is not done at the moment.

The  "MappingException: Association references" problem that you are
experiencing seems to be with the hibernate mappings.

We have released Dithaka this morning. Please try deploying the jars on
your James server. It also contains the third party jars needed. Please
deploy these as well.

Alright you mailForum module seems to be working.

Mmm, What are your aliasmailAddress in table: dithaka_alias_user

Also do you have and idx=ALIAS_MAIL_HOST_ADDRESS in
coefficient_configuration_properties?

On Mon, 2005-07-04 at 18:09 +0100, Jason Meyler wrote:
> Pieter,
> 
> Does this mean that the whole member database needs amending with the 
> new property? I have added a new user, who sent a message. That message 
> ended up as non-delivered.
> 
> Jason
> 
> Pieter van Zyl wrote:
> 
> >On Mon, 2005-07-04 at 09:52 +0100, Jason Meyler wrote: 
> >  
> >
> >>Pieter,
> >>
> >>I attach the Dithaka jars files deployed on James and within the 
> >>mailforum module.
> >>
> >>I deployed these at the beginning of June. After the first start up I 
> >>noticed the new ALIAS_MAIL_HOST_ADDRESS system property and changed this 
> >>to mail.opendgroups.net.
> >>    
> >>
> >If there where members already in the database, and you have the version
> >that uses alias email address ( which you have) then:
> >if you change the ALIAS_MAIL_HOST_ADDRESS then one has to run a script
> >as admin to update existing users alias e-mail address. 
> >
> >We see that ALIAS_MAIL_HOST_ADDRESS should be setup at the start and
> >should not change constantly.  If and administrator does change it at
> >the moment after use, then a script should be run or an admin page
> >should be used to update all users alias email addresses. This page
> >should still be created. 
> >
> >This situation will be on our todo-list and is seen by me as a high
> >priority
> >
> >
> >  
> >
> >>On 30th June I noticed your changes to Dithaka-James and redeployed. On 
> >>1st July redeployed coefficient-mailforum4james.
> >>
> >>The first non-delivered message is logged on 16th June. I can't recall 
> >>changing anything. No properties seem to have been changed. (Is there an 
> >>easy way to check this in the logs?)
> >>    
> >>
> >Do you mean the server logs? If so then no.
> >
> >I am looking into this error: .MappingException: Association references
> >unmapped 
> >
> >I have deployed your jars to my James mail server and everything seems
> >to work. No MappingException.
> >
> >I would suggest building dithaka-base and dithaka-james from CVS to get
> >the latest code onto James copy these to mailForum/lib. And then
> >building the mailForum module again. Then build and deploy your
> >dithaka-james jar as well from CVS.
> >
> >We have been uploading the Dithaka release files into SourgeForge. But
> >it is going slowly. Maybe you can download the binaries tomorrow when it
> >is up? 
> >
> >If you register a new user and do a post to the forum. Does it work?
> >
> >
> >
> >  
> >
> >>Hope this helps. Thanks.
> >>
> >>Jason
> >>
> >>Pieter van Zyl wrote:
> >>
> >>    
> >>
> >>>Jason,
> >>>
> >>>Cab you please e-mail me your Dithaka jars files that you have deployed
> >>>on James?
> >>>
> >>>I am going through the Hiberbate site looking for this error. It seems
> >>>to be related to either missing some mapping files or some of the
> >>>mapping files being incorrect.
> >>>
> >>>Also:have you changed any of the existing e-mail addresses or domains
> >>>after the first deploy?
> >>>
> >>>When did this problem start?
> >>>
> >>>On Fri, 2005-07-01 at 15:37 +0100, Jason Meyler wrote:
> >>> 
> >>>
> >>>      
> >>>
> >>>>Pieter,
> >>>>.MappingException: Association references unmapped 
> >>>>Unfortunately not. Loaded a recompiled coefficient-mailForum4james.jar 
> >>>>into James and update mailforum.ear into JBoss following your guide. 
> >>>>Still no luck with mailing from the forum.
> >>>>
> >>>>The mail server seems to be working ok otherwise - notification of a new 
> >>>>group worked fine. However there are still the same errors/exceptions 
> >>>>being generated by James in the wrapper.log.
> >>>>
> >>>>snip
> >>>>INFO   | jvm 1    | 2005/07/01 13:02:53 | 1309 [Phoenix-Monitor] INFO 
> >>>>cfg.Binder  - Mapping class: org.dithaka.messaging.UserMailPreferences 
> >>>>-> dithaka_usermailpreferences
> >>>>INFO   | jvm 1    | 2005/07/01 13:02:53 | 1310 [Phoenix-Monitor] INFO 
> >>>>cfg.Configuration  - processing one-to-many association mappings
> >>>>INFO   | jvm 1    | 2005/07/01 13:02:53 | 
> >>>>net.sf.hibernate.MappingException: Association references unmapped 
> >>>>class: org.dithaka.messaging.ForumChampion
> >>>>INFO   | jvm 1    | 2005/07/01 13:02:53 |     at 
> >>>>net.sf.hibernate.cfg.Binder.bindCollectionSecondPass(Binder.java:1175)
> >>>>INFO   | jvm 1    | 2005/07/01 13:02:53 |     at 
> >>>>net.sf.hibernate.cfg.Binder$CollectionSecondPass.secondPass(Binder.java:1379)
> >>>>INFO   | jvm 1    | 2005/07/01 13:02:53 |     at 
> >>>>net.sf.hibernate.cfg.Binder$SecondPass.doSecondPass(Binder.java:1355)
> >>>>INFO   | jvm 1    | 2005/07/01 13:02:53 |     at 
> >>>>net.sf.hibernate.cfg.Configuration.secondPassCompile(Configuration.java:639)
> >>>>INFO   | jvm 1    | 2005/07/01 13:02:53 |     at 
> >>>>net.sf.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:791)
> >>>>INFO   | jvm 1    | 2005/07/01 13:02:53 |     at 
> >>>>net.sf.hibernate.util.HibernateUtil.configureHibernateForClasses(HibernateUtil.java:255)
> >>>>......
> >>>>/snip
> >>>>
> >>>>Any ideas?
> >>>>
> >>>>Jason
> >>>>
> >>>>Pieter van Zyl wrote:
> >>>>
> >>>>   
> >>>>
> >>>>        
> >>>>
> >>>>>Jason,
> >>>>>
> >>>>>Did you receive my answer?
> >>>>>
> >>>>>Did it work?
> >>>>>
> >>>>>
> >>>>>On Fri, 2005-07-01 at 08:33 +0100, Jason Meyler wrote:
> >>>>>
> >>>>>
> >>>>>     
> >>>>>
> >>>>>          
> >>>>>
> >>>>>>Hi Pieter,
> >>>>>>
> >>>>>>Thanks for the update. Really good news.
> >>>>>>
> >>>>>>Can you let me know when you will have a chance to look at the problem 
> >>>>>>in my email from yesterday?
> >>>>>>
> >>>>>>Jason
> >>>>>>
> >>>>>>Pieter van Zyl wrote:
> >>>>>>
> >>>>>>  
> >>>>>>
> >>>>>>       
> >>>>>>
> >>>>>>            
> >>>>>>
> >>>>>>>Good day!
> >>>>>>>
> >>>>>>>We are working on the release for today.
> >>>>>>>
> >>>>>>>We are creating the gz files with the binary and the source and doing
> >>>>>>>some testing of the files.
> >>>>>>>
> >>>>>>>We have decided to make the Coefficient release number 0.9.6: there has
> >>>>>>>been more new work added than bug fixes. We are still slowly moving
> >>>>>>>towards an 1.0 release.
> >>>>>>>
> >>>>>>>Dithaka:
> >>>>>>>
> >>>>>>>We will only create releases for Dithaka-Base and Dithaka-James.
> >>>>>>>
> >>>>>>>Dithaka-Tapestry will be released later.
> >>>>>>>
> >>>>>>>The Dithaka release numbers will be 0.7.
> >>>>>>>
> >>>>>>>I want to send out an e-mail later today on all the mailing lists when
> >>>>>>>the release has been done
> >>>>>>>
> >>>>>>>Kindly
> >>>>>>>
> >>>>>>>Pieter
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>    
> >>>>>>>
> >>>>>>>         
> >>>>>>>
> >>>>>>>              
> >>>>>>>
> >>>>>     
> >>>>>
> >>>>>          
> >>>>>
> >>> 
> >>>
> >>>      
> >>>
> >
> >  
> >
> 
> 
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> Coefficient-devel mailing list
> Coe...@li...
> https://lists.sourceforge.net/lists/listinfo/coefficient-devel

The Dithaka team is proud to announce the release of Dithaka version 0.7

Dithaka is a platform that is designed to ease the creation of
collaborative software. At present, it integrates the Jakarta James mail
server with a Jakarta Tapestry front end to offer the services of basic
messaging, document storage and event management. It uses a metadata
layer to link elements (e.g. documents, conversations, events) to domain
objects (e.g. projects). This allows for dynamic structures that can map
the problem domain accurately.

Changes in this version include:
* Aliasing of e-mail addresses
* Activation of James functionality for spam filtering, virus scanning
and loop prevention
* Checking for and handling of large e-mails
* Improved documentation

Please see the release notes for more information.

Dithaka can be downloaded from here:
http://sourceforge.net/project/showfiles.php?group_id=139779

Please note that the Tapestry components are not yet available for
download, but can be retrieved directly from CVS. Instructions for
accessing the CVS repository can be found here:
http://sourceforge.net/cvs/?group_id=139779 

Many thanks to the team (and to Pieter in particular) for the hard work
that went into preparing this release.

Regards
The Dithaka developers

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
MailScanner thanks transtec Computers for their support.

Ahoy!

Ok, I've assembled the infrastructure for the Dithaka static site. See
the new site here:
http://dithaka.sourceforge.net/index.html

As you'll notice, there's not much real content at the moment, but it
should be a good start i.t.o. basic structure (though I'm sure that'll
change a bit as well). 

To edit the site, you'll need to check out the new "doc" module from
CVS[1]. Content is in xdoc format - very easy to edit. 

The site is automagically regenerated nightly, based on what's in CVS.

Some quick and easy edits:
 - TODO list: edit xdocs/todo.xml
 - ChangeLog: edit xdocs/changes.xml
 - FAQ: edit xdocs/faq.fml
 - Installation guides: edit xdocs/install/*.xml
 - Resources Concept document: edit xdocs/concepts/resources.xml
etc.

We can fiddle with look and colours later; for now it's just my maven
default. We do still need a logo, though :)

[1] http://cvs.sourceforge.net/viewcvs.py/dithaka/doc/

Cheers
-- 
Thomas Fogwill <tfo...@cs...>

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
MailScanner thanks transtec Computers for their support.

Good work!

On Tue, 2005-06-07 at 11:41 +0200, Pieter van Zyl wrote:
> > Excellent.  Might be a good idea to mention turning off other mail
> > servers!  I remember having issues with that because e.g. Postgres had
> > some dependency on something.
> I will mention that in the Known_Issues.txt?

Maybe rather in FAQ.{txt|html} and/or in INSTALLING.{txt|html} ??
It's not really a Dithaka issue (i.e. bug/problem) - merely a symptom of
trying to bind 2 services on the same port :)

> Also I have added Richard's comments about the resources and included
> the information about the new event module in Coefficient.

Cool re the resources stuff. I'm not sure the event stuff should live
here, though. It's very coefficienty, and should be included in the
coefficient docs (unless I'm confusing the coefficient event
dispatch/handling mechanism with something totally different in
dithaka :)

I'll try to read through all the docs again today/tomorrow, to check
style/spelling/blahblahblah

Cheers
-- 
Thomas Fogwill <tfo...@cs...>

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
MailScanner thanks transtec Computers for their support.

On Fri, 2005-05-27 at 10:09 +0200, Richard Watson wrote:
> I guess my first thought is that the goals of the project could best
> direct where effort goes - documentation/demo site/slinky website.  Who
> are we trying to attract?
> 
> I've always thought the best initial bunch would be the Tapestry herd -
> they'd find it (or not) useful very quickly because they are the best
> positioned to leverage the components and potentially extend their own
> applications using it, and give us feedback (and hopefully improvement)
> on underlying ideas.  Not sure how close the components are to
> that...been a while.
> 
> Just a thought.  You guys?

Good thinking :)

Getting some Tapestry people to use the components would be cool :)

The Coefficient/OpenDgroups people will also be interested. The
OpenDgroups implementation uses Dithaka and Coefficient. There will be a
demo and presentation of this implementation to the DGroup partners
early in June, after which (I hope) we can expect significant
development activity on both Coefficient and Dithaka.

Given these points, and following some discussion with Richard, I
propose that we focus on the following:
 - README and installation guide
 - Architecture + tech overview
 - "Users" guide - a doc that explains how to integrate Dithaka into
your project, focusing on the use of the Tapestry components
 - Resources: a doc explaining the resources stuff (conceptually). 
 - File extraction stuff - an explanation of how it works, etc.
 - other technical topics in Dithaka, as the demand arises.

I think we should develop the rest of "developers guide" in pieces: as
the need arises for something to be explained (via the mailing list, for
instance), this explanation is distilled into a doc.

A cool website is probably lower down the list; for now, I think we
should focus on s site with content useful to our target audience -
namely Tapestry and Open DGroups developers.

> And the name - as Goodwill explained it to me, you can use it to refer
> to "a collaboration", e.g. musicians might collaborate and that might be
> referred to as a dithaka, and also used as "peers".  Ex nay on the
> tonsils, I say!

+1 :)

-- 
Thomas Fogwill <tfo...@cs...>

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
MailScanner thanks transtec Computers for their support.

Sending this to the dev list as well :)

On Thu, 2005-05-26 at 14:11 +0200, Pieter van Zyl wrote:
> I don't mind doing the documentation, technical docs and read me etc.

Excellent. I think we need txt and html versions for the readmes. For
the technical docs html should be fine. Perhaps Rich could review the
technical docs once you're done? He'd probably be able add something
about how the Resources work.

> What does the name mean?

Dithaka is a Northern Sotho (Sesotho sa Leboa) word that means
(according to http://africanlanguages.com/sdp/)
       1. mates, companions
       2. glands
       3. pips
       4. seeds of the leraka (= vegetable marrow)
       5. eyeballs
       6. tonsils
In our context, I guess "companions" is the most appropriate :)

Richard and Andries will know better.

> We will need to discuss the website creation.

Yip, we do. It would be nice to have a "cool" site with a distinctive
L&F, while still providing useful info. Alternatively, we could do what
coefficient does - i.e. use Maven to generate the site html. See:
http://coefficient.sourceforge.net/

We do still need logos etc.

> On Thu, 2005-05-26 at 14:01 +0200, Thomas Fogwill wrote:
> > What we need:
> > ------------
> > (1) All code in CVS. I'm busy with the initial upload. The 3 separate
> > bits exist in 3 different modules. See (once it's all uploaded):
> > http://cvs.sourceforge.net/viewcvs.py/dithaka/
> > 
> > (2) Project docs. We need:
> >   - technical docs (for developers)
> >   - installation docs 
> >   - README.txt, TODO.txt, KNOWN_ISSUES.txt, etc.
> >   - user guides (maybe??)
> > 
> > (3) Project home page 
> > (html docs to go here: http://dithaka.sourceforge.net/ )
> >   - what the projects is
> >   - what the name means
> >   - technologies used
> >   - some more fluff about the project
> >   - development standards and process docs
> >   - etc.
> > 
> > I would recommend that all of this (docs + project website) be put in
> > CVS. For coefficient, I have a daily cron job that builds and uploads
> > the documentation. This makes it easy to manage and maintain the docs.
> > I'll do something similar for dithaka.
> > 
> > Volunteers for writing some of this?
> > 

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
MailScanner thanks transtec Computers for their support.

2005	Jan	Feb	Mar	Apr	May (2)	Jun (2)	Jul (3)	Aug	Sep (2)	Oct	Nov (1)	Dec
2006	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov (5)	Dec
2014	Jan	Feb	Mar	Apr	May	Jun	Jul (1)	Aug	Sep	Oct	Nov	Dec
2017	Jan	Feb	Mar	Apr	May	Jun	Jul (1)	Aug	Sep	Oct	Nov	Dec
2018	Jan	Feb	Mar	Apr (1)	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec

dithaka-devel Mailing List for Dithaka

dithaka-devel — Mailing list for Dithaka developers