Menu
▾
▴
jpim-devel — Mailing List for jPim Development Discussions
You can subscribe to this list here.
| 2003 |
Jan
(4) |
Feb
(18) |
Mar
(40) |
Apr
(10) |
May
(7) |
Jun
(23) |
Jul
(13) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: <ben...@id...> - 2004-05-21 08:22:53
|
Dear Open Source developer I am doing a research project on "Fun and Software Development" in which I kindly invite you to participate. You will find the online survey under http://fasd.ethz.ch/qsf/. The questionnaire consists of 53 questions and you will need about 15 minutes to complete it. With the FASD project (Fun and Software Development) we want to define the motivational significance of fun when software developers decide to engage in Open Source projects. What is special about our research project is that a similar survey is planned with software developers in commercial firms. This procedure allows the immediate comparison between the involved individuals and the conditions of production of these two development models. Thus we hope to obtain substantial new insights to the phenomenon of Open Source Development. With many thanks for your participation, Benno Luthiger PS: The results of the survey will be published under http://www.isu.unizh.ch/fuehrung/blprojects/FASD/. We have set up the mailing list fa...@we... for this study. Please see http://fasd.ethz.ch/qsf/mailinglist_en.html for registration to this mailing list. _______________________________________________________________________ Benno Luthiger Swiss Federal Institute of Technology Zurich 8092 Zurich Mail: benno.luthiger(at)id.ethz.ch _______________________________________________________________________ |
|
From: <fre...@we...> - 2003-07-24 11:28:09
|
> Hi all, > > After some delay, we are proud to announce the v0.1 public > release. Great news ! > > Documentation can be found at: > http://jpim.sourceforge.net > > For feedback, questions, bug reports etc. please don't hesitate to use the > Sourceforge facilities that can be found at: > http://www.sourceforge.net/projects/jpim > > Enjoy. > Very nice website with good tutorials :-) Cheers, Frederik |
|
From: Dieter W. <di...@wi...> - 2003-07-22 23:47:25
|
Hi all, After some delay, we are proud to announce the v0.1 public release. Documentation can be found at: http://jpim.sourceforge.net For feedback, questions, bug reports etc. please don't hesitate to use the Sourceforge facilities that can be found at: http://www.sourceforge.net/projects/jpim Enjoy. -- The jpim development team. |
|
From: <fre...@we...> - 2003-07-08 11:11:22
|
> > I agree with the above. I was even thinking of "donating" all of the gui code to Columba, for them to work on it because of my 'very' limited free time. Given our timeframe for the upcoming releases I will use your gui component to be able to add this as fast as possible to Columba. Thanks alot :-) > However i still believe that COMPONENTS is the way to go, so making an independent module and having us and others (Columba people) work on it would be the best approach. Yes, we should definitly go for little reusable components. The contact dialog ins't a very good example. I think having a nice date-selector or a complete widget which lets me easily navigate through my whole calender is the way to go. > > > > 4. derive/work on reusable "components" and see whether we can > > provide another module with GUI-Components, the App from 3 > > could be still a testbed also for this components. > > I hope someone will come up and help with the above MVC approach...... MVC is the way to go, big YES here from me :-) Cheers, Frederik |
|
From: <al...@bt...> - 2003-07-07 21:25:10
|
Dieter, Please check: http://yago.sourceforge.net starting some communication with people behind yago maybe will benefit jpim in the future. YAGO is an Organizer Application in Java, and they have 'Contacts' , 'Calendar' , 'Tasks' etc etc Can you suggest them to start using jpim for 'Contacts' and think about moving their basic components to jpim, for everyone's benefit??? Please put some effort on communicating with YAGO. Also, i suggested to a friend of mine (Tasos Vogiatzoglou) to work on a java iCalendar implementation, and he has already started working on it, based on some code he found in Apache's Turbine. I also suggested him that jpim is a perfect place to put his code, so that we can get involved with it. Has he contacted you at all? Looking forward for your reply, Tony |
|
From: <al...@bt...> - 2003-07-07 21:21:35
|
>To all, > > I think it is time to do something about the GUI development, > so that we make best use of our most limited resource time. > > My proposal is to: > 1. remove the GUI code from the library codebase > 2. make the GUI implementation an independent module I agree with the above. I was even thinking of "donating" all of the gui code to Columba, for them to work on it because of my 'very' limited free time. However i still believe that COMPONENTS is the way to go, so making an independent module and having us and others (Columba people) work on it would be the best approach. > 3. target a standalone "Addressbook" implementation starting > from the current codebase; this could be: > a) a demonstration app (proof-of-concept?) > b) a test app for the library Ok i could get in charge of a <simple> standalone "Addressbook" implementation > 5. Put somebody (Tony?) in charge of the GUI App module i am happy with that too > 4. derive/work on reusable "components" and see whether we can > provide another module with GUI-Components, the App from 3 > could be still a testbed also for this components. I hope someone will come up and help with the above MVC approach...... Also, If things start getting bigger (calendars,tasks etc) a framework should be suggested and used for every components (a framework for model/gui/mvc components etc) |
|
From: <al...@bt...> - 2003-07-07 20:42:28
|
> > Just a litle suggestion > > > > > Two issues were important for the release. Changes on the gui, because of recent changes in the model (and Frederik provided a patch for that) and a mimeviewer component in order to open the browser of the operating system at a specific URL. > > > > Instead u could add some methods for adding hyperlink listeners to the panels/components, and then let the program using the gui-components decide what to do or not, when the homepage link is clicked, or if the email-address is clicked. > > > > Stig > > > > Very nice idea, like this, too. > > Frederik > I like the above idea too! Can someone implement it and commit it to the CVS? My free time at the moment barely allows me to check my e-mails... Regards, Tony |
|
From: Dieter W. <di...@wi...> - 2003-07-07 19:14:32
|
To all, I think it is time to do something about the GUI development, so that we make best use of our most limited resource time. My proposal is to: 1. remove the GUI code from the library codebase 2. make the GUI implementation an independent module 3. target a standalone "Addressbook" implementation starting from the current codebase; this could be: a) a demonstration app (proof-of-concept?) b) a test app for the library 4. derive/work on reusable "components" and see whether we can provide another module with GUI-Components, the App from 3 could be still a testbed also for this components. 5. Put somebody (Tony?) in charge of the GUI App module This proposal is based on following arguments: 1. From what I have heard so far, I doubt that we will be really able to create a useful one-for-all addressbook "component": a) because many projects want to impose their own look and feel b) because many projects want to manage their set of properties, probably even derived models 2. The separation will help to keep the codebases maintainable: a) because I foresee growth (calendar, task, notes, bookmarks ?) b) because we can act, work and release rather independently Comments and suggestions are welcome. Regards, Dieter |
|
From: <fre...@we...> - 2003-07-03 00:25:36
|
> Hey > > Just a litle suggestion > > > Two issues were important for the release. Changes on the gui, because of recent changes in the model (and Frederik provided a patch for that) and a mimeviewer component in order to open the browser of the operating system at a specific URL. > > Instead u could add some methods for adding hyperlink listeners to the panels/components, and then let the program using the gui-components decide what to do or not, when the homepage link is clicked, or if the email-address is clicked. > > Stig > Very nice idea, like this, too. Frederik |
|
From: Stig T. <st...@eu...> - 2003-07-02 22:13:08
|
Hey Just a litle suggestion > Two issues were important for the release. Changes on the gui, because = of recent changes in the model (and Frederik provided a patch for that) = and a mimeviewer component in order to open the browser of the operating = system at a specific URL. Instead u could add some methods for adding hyperlink listeners to the = panels/components, and then let the program using the gui-components = decide what to do or not, when the homepage link is clicked, or if the = email-address is clicked.=20 Stig |
|
From: <al...@bt...> - 2003-07-02 21:40:47
|
Ok i am 1 for a release on the 20th of July Two issues were important for the release. Changes on the gui, because of recent changes in the model (and Frederik provided a patch for that) and a mimeviewer component in order to open the browser of the operating system at a specific URL. For the mimeviewer Frederik suggested to use the code from Columba, however mimeviewer are in several packages, and i have no time to decouple stuff. So i ask another time for a mimeviewer.jar ... Will that be a possibility soon? I also agree with releasing the gui code under the Mozilla licence, and you are welcome to do so Regards, Tony PS. Pleease consider a mimeviewer.jar library :) |
|
From: <fre...@we...> - 2003-07-02 11:03:33
|
> > Well, technically speaking there are two possibilities: > 1. Tony releases the code aditionally under MPL > 2. Releasing the code under MPL does not violate the conditions of > the BSD style license (i.e. at least one way compatibility). So, seems I have to wait for Tony's answer... > > >First of all the model has seemed to chang, it was necessary > >to replace some stuff with Iterators to make it compile. > > Correct, I have been warning about this in my posts. Basically all I was aware of your warning. I wanted to give it a try anyway ;-) > 1-n relationships with a preferred item have changed. (Address, > EmailAddress, PhoneNumber). > The preferred item is now remembered in the Associator; the > collections have changed from indexed (they are not naturally indexed > by a number anyway) to unordered collections of unique identifiable > items. > > Related to this changes I have made some adjustments in the backend > (specifically to the ItemHandler interface and all implementing > classes). Ok. > > Hmm, this Exception is thrown if mandatory items are missing from the vCard. > These items are > versitToken.N, versitToken.FN for v3.0 vCards, > as well as > versitToken.N for v2.1 vCards. I'm know much about the vcard specification, but my guess is that the gui-dialog doesn't set these items at all. > > I see about this asap. The patch format prefered is the one from the > jakarta guidelines. > See > http://jwma.sourceforge.net/development/guidelines.html#source/patches > > Did not have time yet to take care for translating this one also to > jpim documentation yet. > As it looks for the moment, I will release the package whether or not > I find time to make a lot of documentation.... > The patch is already in the correct format, anyway I attached another one which also fixes the "preferred-address" stuff. So, forget my last patch :-) Cheers, Frederik |
|
From: Dieter W. <di...@wi...> - 2003-07-01 21:53:55
|
Frederick, >proxy pattern to hide the object tree behind a single >simple contact object Actually this "pattern" is more likely called "Facade". > > >Trying to play around a bit with your code... I was wondering if it >would be possible to use Tony's gui dialog directly in Columba, >without using a jar file. This would mean that you would allow me >to use the gui-sources and change their license in the Columba >sourcetree to MPL (I would of course add a statement where it comes >from, too). >What do you think? Well, technically speaking there are two possibilities: 1. Tony releases the code aditionally under MPL 2. Releasing the code under MPL does not violate the conditions of the BSD style license (i.e. at least one way compatibility). >First of all the model has seemed to chang, it was necessary >to replace some stuff with Iterators to make it compile. Correct, I have been warning about this in my posts. Basically all 1-n relationships with a preferred item have changed. (Address, EmailAddress, PhoneNumber). The preferred item is now remembered in the Associator; the collections have changed from indexed (they are not naturally indexed by a number anyway) to unordered collections of unique identifiable items. Related to this changes I have made some adjustments in the backend (specifically to the ItemHandler interface and all implementing classes). >Then it openened up the dialog correctly, I was able to >save it do disc. My test.csv file looks perfectly. >But when trying to load it fails with the following >exception: > >net.wimpi.pim.util.versitio.versitException: Mandatory tokens missing. > at >net.wimpi.pim.util.versitio.versitParser.validateCard(Unknown Source) > at >net.wimpi.pim.util.versitio.versitParser.bundleObjects(Unknown >Source) > at net.wimpi.pim.util.versitio.versitParser.parse(Unknown Source) > at >net.wimpi.pim.contact.io.vcard.vCardUnmarshaller.parseStream(Unknown >Source) > at >net.wimpi.pim.contact.io.vcard.vCardUnmarshaller.unmarshallContacts(Unknown >Source) > at >net.wimpi.pim.contact.io.vcard.vCardUnmarshaller.unmarshallContact(Unknown >Source) Hmm, this Exception is thrown if mandatory items are missing from the vCard. These items are versitToken.N, versitToken.FN for v3.0 vCards, as well as versitToken.N for v2.1 vCards. Probably these are missing? >here's a patch fixing some import statements necessary to make the >gui parts compile correctly. I also replaced some for-loops to >usage of iterators as that seemed to be changed in the model. >If you need the patch in another format contact me. I see about this asap. The patch format prefered is the one from the jakarta guidelines. See http://jwma.sourceforge.net/development/guidelines.html#source/patches Did not have time yet to take care for translating this one also to jpim documentation yet. As it looks for the moment, I will release the package whether or not I find time to make a lot of documentation.... Regards, Dieter |
|
From: <fre...@we...> - 2003-07-01 14:48:34
|
Hi guys, here's a patch fixing some import statements necessary to make the gui parts compile correctly. I also replaced some for-loops to usage of iterators as that seemed to be changed in the model. If you need the patch in another format contact me. Cheers, Frederik |
|
From: <fre...@we...> - 2003-06-30 23:13:51
|
Hi guys, I stumpled upon an error while trying to load/save a vcard with the gui-dialog. First of all the model has seemed to chang, it was necessary to replace some stuff with Iterators to make it compile. Then it openened up the dialog correctly, I was able to save it do disc. My test.csv file looks perfectly. But when trying to load it fails with the following exception: net.wimpi.pim.util.versitio.versitException: Mandatory tokens missing. at net.wimpi.pim.util.versitio.versitParser.validateCard(Unknown Source) at net.wimpi.pim.util.versitio.versitParser.bundleObjects(Unknown Source) at net.wimpi.pim.util.versitio.versitParser.parse(Unknown Source) at net.wimpi.pim.contact.io.vcard.vCardUnmarshaller.parseStream(Unknown Source) at net.wimpi.pim.contact.io.vcard.vCardUnmarshaller.unmarshallContacts(Unknown Source) at net.wimpi.pim.contact.io.vcard.vCardUnmarshaller.unmarshallContact(Unknown Source) Any ideas? Has this probably something to do with the change in the model which caused the compile errors in the first place? Thanks in advance, Frederik |
|
From: <fre...@we...> - 2003-06-30 22:08:34
|
> > I am wondering if you would also prefer some wrapper (proxy pattern) to > hide the object tree behind a single > simple contact object > (like I use in jwma: > http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/jwma/webmail/src/dtw/ > webmail/model/JwmaContact.java?rev=1.5&content-type=text/vnd.viewcvs- > markup) > http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/jwma/webmail/src/dtw/ > webmail/model/JwmaContactImpl.java?rev=1.5&content-type=text/ > vnd.viewcvs-markup > ). > > I think Stig would have wanted something like this, so if you would > prefer this too, I could start and think of how to realize it. > Basically I think this should be done on application level, once for > the specific type of application, but if we can identify a common > denominator for mail clients, I think we can work on such a package > (and provide it extra, with dependency on jpim and it's dependencies). > Trying to play around a bit with your code... I was wondering if it would be possible to use Tony's gui dialog directly in Columba, without using a jar file. This would mean that you would allow me to use the gui-sources and change their license in the Columba sourcetree to MPL (I would of course add a statement where it comes from, too). What do you think? Cheers, Frederik |
|
From: Dieter W. <di...@wi...> - 2003-06-27 16:57:08
|
Objective: Create a first release to allow people to start working with jpim. Plan: Code Freeze / Tag Date - July 15, 2003 Release Manager - Dieter Wimberger Release Announcement - To the following mailing lists: jpi...@li... jpi...@li... (which I will create on time). Release Criteria: - Prior to the release the documentation needs to be overhauled (I will post a related action item) - A release vote shall take place on the jpim-devel mailing list to approve this plan. Until development community has grown sufficiently, the release vote MUST pass by a reduced "Majority Approval" of jpim committers (that is Tony and me for the moment). |
|
From: Dieter W. <di...@wi...> - 2003-06-25 20:42:55
|
To all, Slightly delayed, I have finished some last updates and I think it is time to officially call for the 0.1 Release Testing. Note that the release will contain GUI code in sources, but it will be excluded from builds (Tony, after the last posts - including your own ones - to this list, I thought this is the best option). Also be aware that the model has changed a bit due to latest discussions on this list (mainly due to enhance the preferred element handling). Everybody is invited to test (jpim can be build from the HEAD on CVS) and to provide feedback (problems, suggestions, show stoppers etc.). Regards, Dieter |
|
From: Dieter W. <di...@wi...> - 2003-06-25 20:37:35
|
Frederik, > This was exactly my thought, too. In the future it would be cool for > example > if you concentrate on creating vCalendar/iCalendar backends and for > the gui-part just provide a couple of calendar widgets which > application > developers can customize and re-use easily. For my part the only > problem > in adding a calendar solution to Columba is just the lack of a good > vCalendar/iCalendar parser. Well, vCalendar/iCalendar is still just a vision. For the moment I am concentrating on working out the contact part. > It would be pretty cool to turn Columba in a complete Workgroup > solution > which won't be possible in the near future without your backend > libraries ;-) Basically this was the idea why I started jpim, I am also principal author and creator of jwma, an MVC webmail client. >>> We are planning to release 0.12.0 on 20.July. Afterwards we really >>> want to >>> move to your stuff. What we need/want is a vcard-parser with the >>> possibility to >>> load/save it to/from a file and the contact editing dialog. >> This should be possible without much problems. > > Sounds great! I have committed my working copy, which includes the latest updates (from discussions on the list) as well as the db package and a serialization based implementation. Probably this could be useful for your project. > I don't want to blame anyone. For me it was totally clear that we > would use your vcard library in Columba. Tony and me, were talking > about this for some months now and I was asking him several times > when you are going to release a version usable for Columba. I actually > moved integration of your stuff to later dates on and on, nevertheless > a lot of people showed interest in a better addressbook and I always > told them to wait for the jpim guys... > Tony also send me screenshots (I actually hosted those screenshots > on our main news site for a couple of weeks) and he also send me > his code for re-viewing. So, this was probably a communication > problem between Tony and you. I did not quite follow discussions between you and Tony; what I thought from his posts to the mailing list, is that you would like to use his GUI, rather then the library. jpim is already nicely able to parse and create vCards since quite a while..... I am wondering if you would also prefer some wrapper (proxy pattern) to hide the object tree behind a single simple contact object (like I use in jwma: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/jwma/webmail/src/dtw/ webmail/model/JwmaContact.java?rev=1.5&content-type=text/vnd.viewcvs- markup) http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/jwma/webmail/src/dtw/ webmail/model/JwmaContactImpl.java?rev=1.5&content-type=text/ vnd.viewcvs-markup ). I think Stig would have wanted something like this, so if you would prefer this too, I could start and think of how to realize it. Basically I think this should be done on application level, once for the specific type of application, but if we can identify a common denominator for mail clients, I think we can work on such a package (and provide it extra, with dependency on jpim and it's dependencies). > > This would be really great :-) > Basically I think the stage the CVS is in atm is RC stage. What is really missing is documentation (other then RFC and javadocs), the docs are rather outdated and incomplete. > Hope to hear from you really soon. I've posted this message to > columba-devel, too. If you need help I suggest you post a message > to our list, I've at least one developer in my mind which was > pretty interested in working on the addressbook stuff. Maybe it > would be a good idea, to already start working with your code > on a different branch, to garanty a smooth transition. I have quite some mail traffic due to lists, so I do not want to join yet another mailing list ;) I would say that your Addressbook implementation could start to work of the current HEAD (as I am going to call for release testing). As a reminder for all, we have adopted jakarta project guidelines, and I would like to try and get things running based on these guidelines. Regards, Dieter |
|
From: <fre...@we...> - 2003-06-25 14:33:56
|
> > Well, I supposed that the view part will always be the most difficult > element. > My suggestion to Tony was to build reusable components (beans) instead > of complete dialogs or > addressbook applications. > I know that it is hard to work on things in the background, but I think > that should be the direction to go. > This was exactly my thought, too. In the future it would be cool for example if you concentrate on creating vCalendar/iCalendar backends and for the gui-part just provide a couple of calendar widgets which application developers can customize and re-use easily. For my part the only problem in adding a calendar solution to Columba is just the lack of a good vCalendar/iCalendar parser. It would be pretty cool to turn Columba in a complete Workgroup solution which won't be possible in the near future without your backend libraries ;-) > > We are planning to release 0.12.0 on 20.July. Afterwards we really > > want to > > move to your stuff. What we need/want is a vcard-parser with the > > possibility to > > load/save it to/from a file and the contact editing dialog. > > This should be possible without much problems. Sounds great! > > There is no need to take over leadership. I am still taking care of > jpim, although I have slowed down a bit > due to the fact that I also have other projects going on as well as > personal issues. > I am taking decisions and I will do take care of deadlines and releases > for the moment. > Another fact is that until recently nobody was even remotely interested > in jpim...... > > Open-Source without community is dead, thus don't blame me. I don't want to blame anyone. For me it was totally clear that we would use your vcard library in Columba. Tony and me, were talking about this for some months now and I was asking him several times when you are going to release a version usable for Columba. I actually moved integration of your stuff to later dates on and on, nevertheless a lot of people showed interest in a better addressbook and I always told them to wait for the jpim guys... Tony also send me screenshots (I actually hosted those screenshots on our main news site for a couple of weeks) and he also send me his code for re-viewing. So, this was probably a communication problem between Tony and you. > > I think I will manage to do so soon. I have been taking care of the > last changes to the model (due to the preferred items) > recently. I will put up a deadline for 20 of July, with a high > probability to be able to finish it earlier. > This would be really great :-) Hope to hear from you really soon. I've posted this message to columba-devel, too. If you need help I suggest you post a message to our list, I've at least one developer in my mind which was pretty interested in working on the addressbook stuff. Maybe it would be a good idea, to already start working with your code on a different branch, to garanty a smooth transition. Cheers, Frederik |
|
From: Dieter W. <di...@wi...> - 2003-06-24 15:51:31
|
Frederik, > You are of course welcome to use our addressbook code, but sadly from a > technical point of view, you can't :-( > Our addressbook makes intensive use of our core framework. The core > framework > provides an empty frame, with a couple of menuentries, etc. The > addressbook > just plugs itself into the frame and adds its specific menu-entries - > same goes > for the toolbar. > We have a plugin-infrastructure we use for our Folder (these are the > contact > store's in Columba and can be compared to a mailbox), not talking about > all the other smaller stuff. > > So, it will be pretty hard to get something usable for you out of the > addressbook > without also using our core infrastructure. Well, I supposed that the view part will always be the most difficult element. My suggestion to Tony was to build reusable components (beans) instead of complete dialogs or addressbook applications. I know that it is hard to work on things in the background, but I think that should be the direction to go. > >> The best scenario is to give us a few weeks, and then join the >> development team of jpim and work on testing and integration. A new >> coder (Stig) has joined the project and will improve jpim a lot, but >> there is a need of a project leader to put some deadlines, and pull >> the strings for a while in order to go for an alpha - beta release. >> Tony, >> To summarize: >> Code is usable and gets mature. >> If your AddressBook moves to jpim, you could get some load off your >> hands. >> A project-leader is required to put some deadlines > > We are planning to release 0.12.0 on 20.July. Afterwards we really > want to > move to your stuff. What we need/want is a vcard-parser with the > possibility to > load/save it to/from a file and the contact editing dialog. This should be possible without much problems. > I don't have the time to lead another project but you should probably > consider > to announce a job on the sourceforge site to get people to know that > you > need more manpower. There is no need to take over leadership. I am still taking care of jpim, although I have slowed down a bit due to the fact that I also have other projects going on as well as personal issues. I am taking decisions and I will do take care of deadlines and releases for the moment. Another fact is that until recently nobody was even remotely interested in jpim...... Open-Source without community is dead, thus don't blame me. > I would recommend you just create a jpim.jar containing your vcard > backend > and release it (open-source == release early, release often). > We are creating open-source software, so nobody expects that your > libary > works perfectly. Just do a release wether its alpha quality or not and > see > what happens :-) I think I will manage to do so soon. I have been taking care of the last changes to the model (due to the preferred items) recently. I will put up a deadline for 20 of July, with a high probability to be able to finish it earlier. Regards, Dieter |
|
From: <fre...@we...> - 2003-06-20 18:55:15
|
Hi Tony, sorry for my late answer - real life keeping me busy... I've send a copy to our mailing-list, too. Maybe someone reading this is interested in helping you out... Don't want to be impolite. > I have made the same question to the rest of the people working on jpim, and in my opinion an alpha release can be here very soon. I don't have any free time now at all, so it's up to the rest of the people. > Another though i had because some people from mailsomething.sf.net are interested in jpim, is Columa to donate the AddressBook code to jpim and sent some people to jpim to work on integration. You are of course welcome to use our addressbook code, but sadly from a technical point of view, you can't :-( Our addressbook makes intensive use of our core framework. The core framework provides an empty frame, with a couple of menuentries, etc. The addressbook just plugs itself into the frame and adds its specific menu-entries - same goes for the toolbar. We have a plugin-infrastructure we use for our Folder (these are the contact store's in Columba and can be compared to a mailbox), not talking about all the other smaller stuff. So, it will be pretty hard to get something usable for you out of the addressbook without also using our core infrastructure. > The best scenario is to give us a few weeks, and then join the development team of jpim and work on testing and integration. A new coder (Stig) has joined the project and will improve jpim a lot, but there is a need of a project leader to put some deadlines, and pull the strings for a while in order to go for an alpha - beta release. > Tony, > To summarize: > Code is usable and gets mature. > If your AddressBook moves to jpim, you could get some load off your hands. > A project-leader is required to put some deadlines We are planning to release 0.12.0 on 20.July. Afterwards we really want to move to your stuff. What we need/want is a vcard-parser with the possibility to load/save it to/from a file and the contact editing dialog. I don't have the time to lead another project but you should probably consider to announce a job on the sourceforge site to get people to know that you need more manpower. I would recommend you just create a jpim.jar containing your vcard backend and release it (open-source == release early, release often). You dialog doesn't use our infrastructure for resource-handling, etc. and the most important point: it doesn't follow our user-interface guidelines, which makes it pretty useless for us. I therefore would love to have you allow me to directly integrate the sources of your editor-gui in Columba, so that we are able to apply our changes. Nevertheless we should be able to provide you with bugfix patches. Reading in your last message, I heared that Stig from mailtosomething doesn't have the time either to help you out. So, its probably not a good idea to make the jpim project even bigger in creating a complete addressbook software. Instead I recommend you concentrate on the vcard/vcalender stuff, which is really needed by many projects out there. Most people will have problems using your editor because of the different user-interface guidelines anyway. Nevertheless its a very nice proof of concept and people should use this editor as a starting point to integrate your stuff into their applications. If you would be able to just release the vcard-parser we could instantly try to integrate it in Columba. This way we could give you feedback from an integrators point of view on how to make your library even better. This would also mean that it would be much more motivating for your team, because they work to allow an existing application to work out of the box based on their work. This would also most probably lead to more interaction between our teams which is a good thing for both of us. We are creating open-source software, so nobody expects that your libary works perfectly. Just do a release wether its alpha quality or not and see what happens :-) Hope to hear from you soon! Cheers, Frederik |
|
From: Stig T. <st...@eu...> - 2003-06-14 18:54:37
|
Hey > I was away for a few weeks, and i dont have lots of free time at the = moment, due to militaty service :( so its up to you and Dieter to = improve jpim, and i would recommend that you get cvs access on jpim, = work on it, and use it as a library (jpim.jar) in your project. You = could teach us a few things but also learn a few things if you join the = development team. I dont really have time. I said in another mail to this list, that u can = use my changes if u find them good. But I am reluctant to join another = project. My experience is I simply dont work on it coz im to hung up = with my own project. Furthermore, as u will notice from reading the last = mails, I have done changes to the model, and I cant use jpim as a = libary. Or at least not the code from ur cvs. Coz I have made changes to = it, and I will continue to do so when I need it.=20 I am willing to help u change ur code though, regarding my changes, if u = find some of it (for example the gui) helpfull.=20 >=20 > 1. AddressBook >=20 > I guess mailsomenthing will need an AddressBook to hold the vCards. = Columba (another e-mail client written in java columba.sf.net ) will use = the jpim library as soon as we make a release. They already have an = Addressbook (that needs some work) and someone has volunteered to put = some work into it. If you don't have an AddressBook, maybe we could all = collaborate. We could ask columba people to donate their AddressBook = code to jpim (and i believe they will). Then we could work on it = (columba people, jpim people, and mailsomething people) so all 3 = projects start sharing some good code, and make an excellent AddressBook = that uses vCards. I think its a good thing, collaborating, and as I see it, my discussions = with Dieter is allready some form of collaborating - exchanging ideas = and views on things. Maybe we dont aggree on everything, but to me that = discussion has been helpfull.=20 If u read the last correspondance to this list I think its clear that I = allready have done a 'ContactBook'. AddressBook is to me different, that = is a list of MailAddresses. I have allready done that and are currently = working on synchronization with an imap (contact)-mailbox. I am not sure = its worth collaborating (using same code) doing this... kinda depends = on the projects. My 'contact-list' is very simply. I think we could = collaborate on for example stuff like synchronization. But, my = synchronization is basicly done through my own mailmodel, and then it = kinda gets unuseable for columba. But I dont mind discussing and helping = eachother. Some weeks ago I tested columba (by the way) and I got some = error when connecting to my imap account that made it totally unusable. = I posted a bug at their site, but as I know noone have responded.=20 > I did not like refactoring. That could be personal taste, but i tried = to have the gui code use the same formatting as the code of the model. Well. When I realized I needed to make some changes to the model, and = that Dieter wasnt interested in changes in his model, I placed to code = at mailsomething cvs - I work on the code several places, and it gives = me a bit of trouble if I cant get the changed code. When I did that I = thought - well, then I can just as well refactor etc. I use eclipse, and = I am very glad with the format of eclipse=B4s refactoring.=20 >=20 > Using com.Ostermiller.util for example in Utils was a good thing. = However you mixed GPL code (Ostermiller's code) with BSD code (jpim's = code) and that is not a good thing. You should instead try to use it as = a library. I had the same issued with JCalendar, and Dieter pointed me = the correct way... Please explain to me why that is a problem? I dont understand that. = Firstly ostermillers code doesnt exist in a jar, not when I found it. = Secondly, as I allready mentioned, I cannot use urs as a jar. I could = jar it myself, in its own jar, and then keep it seperate when = distributing my app, but I dont think that is very good, since if u at = some point upload a jar at the jpim project, people might think the jar = I am distributing with my project (with ur model and some changes) is = the same.=20 I ofcourse intent to mention all used libaries/projects in the credits. = And their different licenses. As for licenses I am a bit confused with = jpim. I found some license at ur cvs, and it didnt looked like the bsd = license (I read the bsd license before I decided to build my contacts = upon ur model).=20 By the way. I did another change to ur gui code which u might be = interested in - the 'Main' class initialized the Filechooser for loading = vcard when intializing the code. Only problem with that is, that the = JFileChooser is SLOW loading. After I changed that I got the startup of = ur tabbedpane (in a frame) down to 0,7 seconds on my computer, compared = to the 3,5 secs it took with ur current code.=20 Stig |
|
From: <al...@bt...> - 2003-06-14 17:04:23
|
Dear Stig, I was away for a few weeks, and i dont have lots of free time at the moment, due to militaty service :( so its up to you and Dieter to improve jpim, and i would recommend that you get cvs access on jpim, work on it, and use it as a library (jpim.jar) in your project. You could teach us a few things but also learn a few things if you join the development team. 1. AddressBook I guess mailsomenthing will need an AddressBook to hold the vCards. Columba (another e-mail client written in java columba.sf.net ) will use the jpim library as soon as we make a release. They already have an Addressbook (that needs some work) and someone has volunteered to put some work into it. If you don't have an AddressBook, maybe we could all collaborate. We could ask columba people to donate their AddressBook code to jpim (and i believe they will). Then we could work on it (columba people, jpim people, and mailsomething people) so all 3 projects start sharing some good code, and make an excellent AddressBook that uses vCards. 2. Changes in cvs I saw some of the changes you made to jpim in mailsomething CVS and most of them where excellent. I have to make some comment however: I did not like refactoring. That could be personal taste, but i tried to have the gui code use the same formatting as the code of the model. Using com.Ostermiller.util for example in Utils was a good thing. However you mixed GPL code (Ostermiller's code) with BSD code (jpim's code) and that is not a good thing. You should instead try to use it as a library. I had the same issued with JCalendar, and Dieter pointed me the correct way... Best regards, Tony |
|
From: Dieter W. <di...@wi...> - 2003-06-10 18:43:44
|
Stig, > U aware if vcards have a mimetype? I think the mime type for vCard 2.1 is "application/directory" and for 3.0 it is "text/directory" > I might need to attach some 'lastediteddate' attribute to the contact. I suppose you might be able to make good use of the following existing methods: public Date getCurrentRevisionDate(); public void setCurrentRevisionDate(Date date); Regards, Dieter On 6/10/03 13:38, "Stig Tanggaard" <st...@eu...> wrote: > Hey > > U aware if vcards have a mimetype? Like 'text/html'. I was thinking that I > would do synchronization of contact-info by simply uploading the vcards in a > mail at a userspecified mailbox (when the user uses imap), and then download > theese (at another location) into the contactlist. And if vcards have a > mimetype it will be a bit easier, coz then I can upload them with that > mimetype and then other programs can understand them too (if they have support > for the standard). > > > Stig |
