grouptime-developers Mailing List for group.time 2002 (Page 2)
Status: Pre-Alpha
Brought to you by:
sauanimal
Menu
▾
▴
grouptime-developers — Information, announcements etc. meant for the grouptime team members.
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(43) |
Oct
(4) |
Nov
|
Dec
(1) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Jan U. <ja...@ko...> - 2002-09-09 14:00:24
|
Ok, changed some standards, some bugfixes, some additions. Is this acceptable for all: http://www.realtime.ee/~sau/coding_standards.zip If something doesn't like, let us know, and I'll fix it. If now feedback havent received by the end of today 09.09.2002, 10pm GMT 0, then I'll take that all agreed and I'll declare this doc for final. May the source be with you Jan Urva |
|
From: Andrey H. <and...@ma...> - 2002-09-09 13:51:51
|
Hi all, I think that every module must export and use constants for paths to the files when used in include/requre require PATH_TO_CONCTACTS_CLASSES.'ccontact.class.php'; or require PATH_TO_CONTACTS.'somefile.php'; Thus the installation can be easy and everyone can change paths and everything will work (hopefully). I hope that you got the idea. Andrey Jan : Could you add all commented stuff to the document and resend it again as RC (release candidate). |
|
From: Jan U. <ja...@ko...> - 2002-09-09 12:54:29
|
> hi all!
>
> i have some more comments about coding standards.
>
> In section 2 (Standard) it should be "introduce" and not "introduces".
ok,bugfixed :)
> A doubt: so in resume, we agreed with 4 spaces. Is that right?
correct
> i dont agree with uppercase html tags. Lowercase html tags
> makes the writing of documents easier. Why using capitalized
> ones? I dont know why...
ok, as you wish :)
> the class files problem still exists...
> Putting '_' (underscore) in file names is ugly! i suggest:
> MyClass.class.php for class MyClass
ok, let's make them so: MyClass.class.php
> or
>
> myclass.class.php for class MyClass (this is worse)
>
> whats the problem with filenames having capitalized letters?
> When we want to instanciate an instance of a class, do we
> forget to capitalize the right letter? I dont think so...
> This stands for filesnames too. I have an idea for classes
> handling. We could use something like the import contruct of java.
> Do you know this? Its like this:
> For example: supose that i want to use the class MyClass in
> my php script. So i write: <?
> import("net.sourceforge.grouptime.MyClass");
>
> $myInstance = new MyClass;
> ?>
> this will import the MyClass definition to my script so i can
> use it normaly. In this case the class file would be in the
> directory classes/net/sourceforge/grouptime/
> where classes directory is our class repository.
> This is used to avoid classes with the same names but with
> diferent implementations. This is done using and URI that is
> normaly defined based on the application URL. What do you
> think? Have you ever worked with java?
I don't think nothing now, don't know, but this is not the issue of the
coding standard, isn't it!?
> About why i suggested MyFunctions.func.php instead of
> MyFunctions.fun.php, this is only because of the number of
> letter used in class filenames (class - 4) and for functions
> filenames (fun - only 3). Thats why, but this is only litle
> details! :-P
Ok, then it stays MyFunctions.fun.php :)
> In section 2.2 (Functions, classes, methods) theres an error
> in classnames example: the name of contructor method must
> have the same name than the class (in this case MyClassName
> and not myClassName). Ok? :-)
bugifxed
|
|
From: Jan U. <ja...@ko...> - 2002-09-09 12:54:27
|
> Hi all,
> I got some comments on the coding standard:
> 1)I don't see any reason to use short tags instead of long in
> all places. Exception is<?=$some_var;?> which is faster to
> write than <?php echo $some_var;?> . But I see that
> <?=$some_var;?> is not preferred.
This <? ehco ... ?> it's more clearer. Therefore it stays.
2)Indentaion. IMO
> indentation must be in tabs. Every good editor can be
> configured how much spaces(visual) tab to be - I use 4 spaces
> for tab but someone can use 8 spaces. So I think that there
> should not be any indentation spaces.
qutoe:indentation should be used four (4) whitespaces or TAB's that act
like four (4) whitesspaces.
therefore, we allow both variants but, the TAB must be 4 whtiespace :)
3)Class names. Let's
> get it like C++ and add 'C' as a prefix. So class names like
> CMyClass, CFoo, CBar.
I don't see no point, so we don't change that.
4)$class = new MyClassName;
> Why not CMyClassName() - no matter there are no params this
> is call to method.
same as previous
5)if operator:
> Which is better :
> if ($some_var == 1) {
>
> } else {
>
> }
> OR
> if ($some_var == 1){
>
> }else{
> }
>
> I prefer the second one but the former is K&R style that is
> used in php sources I when i wrote patches I use it. I think
> we must decide which one we will use.
We'll use the first one, space betweem ) {
6)Strict types: If one
> var is used as int it will be int to the end of the script.
> In conditions IMO it is better to use === and !== to check
> and type. Otherwise problems can be faced. Consider this :
> <?php $str_val = '0'; if ($str_val) echo "one"; else echo
> "two"; ?> This will output "two" no matter that
> strlen($str_val) is not 0. This is type juggling. So use ===
> to check.
I think this is not a matter of coding standard, it's more like the
feature of programming language... meaning we can use it.
7)Casting : I prefer this : $i_var =
> (int)$some_str_val; Other are (string), (float)
Acceptable
8)File comments : I think we have to phpdoc compatible comments.
> LIke this: <?php
> /**
> Class that has all the features of input validatin
>
> @author Andrey Hristov
> @version $Id: cinputvalidate.class.php,v 1.25 2002/09/02
> 16:20:21 andrey Exp $ @package Group_Time @module
> Input_validation */
9)Function comments :
> /**
> * Checks for validity.
> *
> * @access public
> * @param array $check_vars Array with properties of the
> category to be created.
> * @return array $ret_ar 1. VALIDATE_FAIL - if data
> validation failed at some point (about 2 validations).
> * 2. GENERAL_OPERATION_SUCCESSFUL if there is no
> error from 1 to
> 1.
> */
Don't like them,therefore we don't use them
> 10)Statuses returned from methods. To extend TRUE/FALSE .
> Look above and see - if validation failed array is returned
> - array(VALIDATE_FAIL, 2); The second parameter is used to
> track where in the code the validation failed. If everything
> went ok - then
> array(GENERAL_OPERATION_SUCCESSFUL) is returned. There can be
> any other var after the first - it can be used to return vars
> from the function. In this case VALIDATE_ is namespace for
> validation constants. GENERAL_ is namespace for general
> constants and so on.
Agreed.
11)Namespaces for constants - if some
> module introduces constants they must be written and used in
> uppercase. No matter that php is case insensitive by default
> for constants. Every module has a prefix and all constants
> has to have prefix. Uppercased constants applies also to TRUE/FALSE.
Agreed
Jan
|
|
From: Lucas R. <lu...@uf...> - 2002-09-09 12:43:38
|
> IMO lower letters are best. On systems that are case sensitive we must > escape the problems with the names. Whats IMO? Thats ok then. We keep lowercased filenames so. > AFAIK import is reserved word in ZE2 so we will have problems. Whats AFAIK? Thats not a problem, we put gtImport then. I asked your opinioon about the idea itself. implementation details like this are not problems in fact.. :-) peace --lucasr |
|
From: Jan U. <ja...@ko...> - 2002-09-09 12:32:01
|
Andrey want me to post this one, he has some kind of trouble
>>>>>>
Hi all,
I got some comments on the coding standard:
1)I don't see any reason to use short tags instead of long in all
places. Exception is<?=$some_var;?> which is faster to write than <?php
echo $some_var;?> . But I see that <?=$some_var;?> is not preferred.
2)Indentaion. IMO indentation must be in tabs. Every good editor can be
configured how much spaces(visual) tab to be - I use 4 spaces for tab
but someone can use 8 spaces. So I think that there should not be any
indentation spaces. 3)Class names. Let's get it like C++ and add 'C' as
a prefix. So class names like CMyClass, CFoo, CBar. 4)$class = new
MyClassName;
Why not CMyClassName() - no matter there are no params this is call to
method. 5)if operator:
Which is better :
if ($some_var == 1) {
} else {
}
OR
if ($some_var == 1){
}else{
}
I prefer the second one but the former is K&R style that is used in php
sources I when i wrote patches I use it. I think we must decide which
one we will use. 6)Strict types: If one var is used as int it will be
int to the end of the script. In conditions IMO it is better to use ===
and !== to check and type. Otherwise problems can be faced. Consider
this : <?php $str_val = '0'; if ($str_val) echo "one"; else echo "two";
?> This will output "two" no matter that strlen($str_val) is not 0. This
is type juggling. So use === to check. 7)Casting : I prefer this :
$i_var = (int)$some_str_val; Other are (string), (float) 8)File
comments : I think we have to phpdoc compatible comments. LIke this:
<?php
/**
Class that has all the features of input validatin
@author Andrey Hristov
@version $Id: cinputvalidate.class.php,v 1.25 2002/09/02 16:20:21
andrey Exp $ @package Group_Time @module Input_validation */ 9)Function
comments :
/**
* Checks for validity.
*
* @access public
* @param array $check_vars Array with properties of the category to be
created.
* @return array $ret_ar 1. VALIDATE_FAIL - if data validation failed
at some point (about 2 validations).
* 2. GENERAL_OPERATION_SUCCESSFUL if there is no error from 1 to
1.
*/
10)Statuses returned from methods. To extend TRUE/FALSE .
Look above and see - if validation failed array is returned -
array(VALIDATE_FAIL, 2); The second parameter is used to track where in
the code the validation failed. If everything went ok - then
array(GENERAL_OPERATION_SUCCESSFUL) is returned. There can be any other
var after the first - it can be used to return vars from the function.
In this case VALIDATE_ is namespace for validation constants. GENERAL_
is namespace for general constants and so on. 11)Namespaces for
constants - if some module introduces constants they must be written and
used in uppercase. No matter that php is case insensitive by default for
constants. Every module has a prefix and all constants has to have
prefix. Uppercased constants applies also to TRUE/FALSE.
This is for now. Please comment. :))
Andrey
<<<<<
|
|
From: Lucas R. <lu...@uf...> - 2002-09-09 12:13:01
|
hi all!
i have some more comments about coding standards.
In section 2 (Standard) it should be "introduce" and not "introduces".
A doubt: so in resume, we agreed with 4 spaces. Is that right?
i dont agree with uppercase html tags. Lowercase html tags makes the writing of documents
easier. Why using capitalized ones? I dont know why...
the class files problem still exists...
Putting '_' (underscore) in file names is ugly! i suggest:
MyClass.class.php for class MyClass
or
myclass.class.php for class MyClass (this is worse)
whats the problem with filenames having capitalized letters? When we want
to instanciate an instance of a class, do we forget to capitalize the right letter? I dont think so...
This stands for filesnames too.
I have an idea for classes handling. We could use something like the import contruct of java.
Do you know this? Its like this:
For example: supose that i want to use the class MyClass in my php script. So i write:
<?
import("net.sourceforge.grouptime.MyClass");
$myInstance = new MyClass;
?>
this will import the MyClass definition to my script so i can use it normaly.
In this case the class file would be in the directory classes/net/sourceforge/grouptime/
where classes directory is our class repository.
This is used to avoid classes with the same names but with diferent implementations. This
is done using and URI that is normaly defined based on the application URL.
What do you think? Have you ever worked with java?
About why i suggested MyFunctions.func.php instead of MyFunctions.fun.php, this is only because
of the number of letter used in class filenames (class - 4) and for functions filenames (fun - only 3).
Thats why, but this is only litle details! :-P
In section 2.2 (Functions, classes, methods) theres an error in classnames example:
the name of contructor method must have the same name than the class (in this case
MyClassName and not myClassName). Ok? :-)
the rest is OK!!! :-)
peace!
--lucasr
|
|
From: Jan U. <ja...@ko...> - 2002-09-09 11:23:18
|
Hi! Can I get from developers the agreement, that we can say, this coding standard is acceptable and we declare this to our final release for now!? The last release can be found here: http://www.realtime.ee/~sau/coding_standards.zip If something doesn't like, let us know, and I'll fix it. If now feedback havent received by the end of today 09.09.2002, 10pm GMT 0, then I'll take that all agreed and I'll declare this doc for final. May the source be with you Jan Urva |
|
From: Jan U. <ja...@ko...> - 2002-09-09 07:24:25
|
Hi! > But, if > we agree with <? ?> that's fine, because I usually use that too :) Ok, then it's descided, we use <? ?> :) > Other suggestion: When we need to unconditional including > files we must > use require_once and when conditional including files we use > include_once. This will ensure that files are included only > once. (from > PEAR coding standard too :) ) Good point, have to remind to write ti to the standard. Jan |
|
From: Hansen <az...@ma...> - 2002-09-09 07:21:11
|
> Hi! > > >>I want to comment: >>- Point 2.1, "the start and the end tags of the PHP script >>must be <? and ?>. Do not use <?php tags." Why? I think <?php >>is more standard. > > > Actually there isn't any constructive reasons, I just like <? more than > <?php. It's more elegant if you like :) > I'm quote from PEAR coding standard: "Always use <?php ?> to delimit PHP code, not the <? ?> shorthand. This is required for PEAR compliance and is also the most portable way to include PHP code on differing operating systems and setups." (http://pear.php.net/manual/en/standards.tags.php) But, if we agree with <? ?> that's fine, because I usually use that too :) Other suggestion: When we need to unconditional including files we must use require_once and when conditional including files we use include_once. This will ensure that files are included only once. (from PEAR coding standard too :) ) Regards Hansen |
|
From: Jan U. <ja...@ko...> - 2002-09-09 07:15:44
|
> Ok.
> I'll change that, there is no problem, just have to change
> the regex. I can also create a new method where you can
> choose the "opentag" you want to use (and its matching
> 'closetag'). And I can set "{" as default. What do you think?
Thanx, write them also in spec, new methods then setOpenTag($tag),
default { and setCloseTag($tag), default }.
> About tabs and spaces there is no problem for me, just choos
> and I'll agree. :)
Yeah, hope that everybody else are also so tolerant :)
Jan
|
|
From: Cosimo V. <co...@da...> - 2002-09-09 07:11:00
|
Il lun, 2002-09-09 alle 09:34, Jan Urva ha scritto:
> TMPL tags are that way for two reasons:
> A) HTML IDE software (Dreamweaver and so on) ignore those tags
> as they are between "<" and ">". So you can edit this template
> files with these applications without damaging layout.
> B) In case, one or more of this variables, are not passed to the
> templates the browser will ignore this tags (they won't be displayed).
>
> Can't this be remade!? I know that some of the template engines use the
> {}
> instead of <>. I think using the {} will give the better impression,
> what is in the page etc... don't you agree!?
Ok.
I'll change that, there is no problem, just have to change the
regex. I can also create a new method where you can choose the
"opentag" you want to use (and its matching 'closetag').
And I can set "{" as default.
What do you think?
About tabs and spaces there is no problem for me, just choos and
I'll agree. :)
Cosimo.
|
|
From: Jan U. <ja...@ko...> - 2002-09-09 06:39:06
|
Hi!
> I want to comment:
> - Point 2.1, "the start and the end tags of the PHP script
> must be <? and ?>. Do not use <?php tags." Why? I think <?php
> is more standard.
Actually there isn't any constructive reasons, I just like <? more than
<?php. It's more elegant if you like :)
> - Point 2.1 too, database query. Can we separate the SQL
> portion (with string variable)? That's make the SQL easy to
> build dynamic.
Yes, we can, actually I didn't mentioned this in the standard, I just
wrote how should be written the SQL query itself. Of couse, we can
use
$sql = "SELECT field FROM table";
$result = dbQuery($sql);
or
$result = dbQuery("SELECT field FROM table");
> - Correction about typo :) Point 2.3, "all the custom
> function ...", should $HTTP_GET_VARS is $_GET ?
Yes, thnx :)
Jan
|
|
From: Hansen <az...@ma...> - 2002-09-09 03:14:24
|
I want to comment: - Point 2.1, "the start and the end tags of the PHP script must be <? and ?>. Do not use <?php tags." Why? I think <?php is more standard. - Point 2.1 too, database query. Can we separate the SQL portion (with string variable)? That's make the SQL easy to build dynamic. - Correction about typo :) Point 2.3, "all the custom function ...", should $HTTP_GET_VARS is $_GET ? The rest is OK :) Hansen Jan Urva wrote: > Hi! > > We done some fork for a while no with the project coding > standards, and now i dare to say, that this is quite near to > the FINAL document, i call it thouhg pre-FINAL, hope you > can get some time to read it through. You can reach it > from our home: > > http://grouptime.sourceforge.net/coding_standards.zip > > Thanx for Lucas who helped me out a little bit :) > > Waiting enormous feedback to this doc also, > Jan Urva |
|
From: <lu...@uf...> - 2002-09-08 14:54:48
|
Hi all! In peace! first of all, congratulations Jan, the doc is great! Here are some comments about this first version of standards The part of class names and its files are confusing. First its said that = class files should be named with MyClass.class.php for the class MyClass. Then = its said after that "class names should match it=92s lover cased file-based n= ame: myclass.php". I think the first one is the best. What do u think? I dont agree with 2 spaces for identation. I think it should be 3 beacaus= e it keeps the identation cleaner! TABs are horrible! :-) If everyone agree wi= th 2 then its ok for me. I suggest that function collection files (we will avoid the use of functi= ons!!) should be named like this MyFunctions.func.php instead of MyFunctions.fun= .php I liked a lot the comments standards! i have made a new version of the coding standards doc draft with some eng= lish bugs and a rewriten introduction text. I didnt change anything about the = coding standard itself beacuse i think this must be decided in group. Jan, have a look ok? peace for all! --lucasr ------------------------------------------------- This mail sent through IMP: http://www.webmail.ufba.br |
|
From: Cosimo V. <co...@da...> - 2002-09-07 18:13:49
|
Il sab, 2002-09-07 alle 17:52, Jan Urva ha scritto:
> A) Are we sure we want to use spaces (2) instead of tabs?
> Using tabs let anyone edit (and see) files as preferred
> (just setting tab indentation inside editor), using
> spaces doesn't.
> Yes, i'm sure i want to use 2 spaces, because usually the tabs are
> very different lenght in different users and it ends up kind of a
> messy doc. After a while, noone want's to see such crappy idented
> files. So - 2 spaces stays.
For me it's ok, but tabs are client-dependent.
So you see what you want to see.
With spaces you see what "I" want you to see.
No problem for me, but it's not a nice standard in my opinion.
> B) Any file of the project should also have, IMO, the following
> rows:
> * This program is free software; you can redistribute it and/or modify
> * it under the terms of the GNU General Public License as published by
> * the Free Software Foundation; either version 2 of the License, or
> * (at your option) any later version.
> *
> * This program 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 General Public License for more details.
> *
> * You should have received a copy of the GNU General Public License
> * along with this program; if not, write to the Free Software
> * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
> *
> * (See the included file COPYING)
> Agreed in some part, i think that we don't need to add it to the EVERY
> file beginning, because we add the full licence text anyway with the
> product. But maybe these lines should be added in the beginning of the
> initial file (in our case index.php)!?
>
Have to see, I'm not sure....
> Also a little addition of this template engine we've been discussing. All
> fine, but i'd like to see the template tags like following:
> {TMPL_VAR NAME=XXXXX}
TMPL tags are that way for two reasons:
A) HTML IDE software (Dreamweaver and so on) ignore those tags
as they are between "<" and ">". So you can edit this template
files with these applications without damaging layout.
B) In case, one or more of this variables, are not passed to the
templates the browser will ignore this tags (they won't be displayed).
> Also, maybe method names should be renamed so, that they fit to our
> standard, i.e:
> setName($template_name)
> openLog($logfile, $loglevel)
> closeLog()
> setOpenTag($open_tag)
> setExtensions($ext)
> setClassPath($path)
> setClassName($name)
> forceCompilation()
> setParam($var, $value)
> getOutput()
No problem, except for "getOutput()".
Why "get" ? The output method will let you have html on standard
output, you can't get it. But it's only my opinion.
> What do you guys think!?
> With regards,
> Jan
Cosimo.
|
|
From: Jan U. <sa...@kr...> - 2002-09-07 15:52:36
|
A) Are we sure we want to use spaces (2) instead of tabs?
Using tabs let anyone edit (and see) files as preferred
(just setting tab indentation inside editor), using
spaces doesn't.
Yes, i'm sure i want to use 2 spaces, because usually the tabs are
very different lenght in different users and it ends up kind of a
messy doc. After a while, noone want's to see such crappy idented
files. So - 2 spaces stays.
B) Any file of the project should also have, IMO, the following
rows:
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
*
* This program 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 General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
*
* (See the included file COPYING)
Agreed in some part, i think that we don't need to add it to the EVERY
file beginning, because we add the full licence text anyway with the
product. But maybe these lines should be added in the beginning of the
initial file (in our case index.php)!?
Also a little addition of this template engine we've been discussing. All
fine, but i'd like to see the template tags like following:
{TMPL_VAR NAME=XXXXX}
Also, maybe method names should be renamed so, that they fit to our
standard, i.e:
setName($template_name)
openLog($logfile, $loglevel)
closeLog()
setOpenTag($open_tag)
setExtensions($ext)
setClassPath($path)
setClassName($name)
forceCompilation()
setParam($var, $value)
getOutput()
What do you guys think!?
With regards,
Jan
|
|
From: Cosimo V. <co...@da...> - 2002-09-07 13:50:01
|
Il sab, 2002-09-07 alle 15:32, Jan Urva ha scritto: > Hi! > http://grouptime.sourceforge.net/coding_standards.zip > Waiting enormous feedback to this doc also, > Jan Urva Just two things: A) Are we sure we want to use spaces (2) instead of tabs? Using tabs let anyone edit (and see) files as preferred (just setting tab indentation inside editor), using spaces doesn't. B) Any file of the project should also have, IMO, the following rows: * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by * the Free Software Foundation; either version 2 of the License, or * (at your option) any later version. * * This program 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 General Public License for more details. * * You should have received a copy of the GNU General Public License * along with this program; if not, write to the Free Software * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. * * (See the included file COPYING) What do you think? Cosimo. |
|
From: Jan U. <sa...@kr...> - 2002-09-07 13:32:42
|
Hi! We done some fork for a while no with the project coding standards, and now i dare to say, that this is quite near to the FINAL document, i call it thouhg pre-FINAL, hope you can get some time to read it through. You can reach it from our home: http://grouptime.sourceforge.net/coding_standards.zip Thanx for Lucas who helped me out a little bit :) Waiting enormous feedback to this doc also, Jan Urva |
|
From: Jan U. <sa...@kr...> - 2002-09-06 22:39:06
|
Hi! I've done now the first draft of the general core documentation. You can reach it from sf: http://grouptime.sourceforge.net/grouptime_documentation.zip PS! To Lucas: yes, the plan was that you make the DAC, but now somehow it's documented, i'm sure it's not so good as you would make it. Therefore - don't be shy about commenting and giving feedback. This of course applies to all of the members Waiting enormous feedback, Jan Urva |
|
From: Lucas R. <lu...@uf...> - 2002-09-06 15:37:50
|
Wasnt it me that was suposed to do the DAC docs draft? ??? peace --lucasr On Fri, 6 Sep 2002 13:50:35 +0200 "Jan Urva" <ja...@ko...> wrote: > Hi! > > A little bit work and now the first group.time on-line > meeting summary is up in the forum. You all can reach to > this by following url: > > > If something seems missing, wrong, right etc., post feedback > to the forum or mailing list. > > With regards > Jan Urva aka Sau > > > > ------------------------------------------------------- > This sf.net email is sponsored by: OSDN - Tired of that same old > cell phone? Get a new here for FREE! > https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390 > _______________________________________________ > Grouptime-developers mailing list > Gro...@li... > https://lists.sourceforge.net/lists/listinfo/grouptime-developers |
|
From: Jan U. <ja...@ko...> - 2002-09-06 10:43:24
|
Sry, forgot the url: http://grouptime.sourceforge.net/?main=12&task=view_topic&topic_id=26&fo rum_id=13 Jan Urva Senior Developent Specialist Realtime Ltd. GSM: +(372) 56 657 936 Phone@Work: +(372) 6 999 687 E-Mail: ja...@re... ---------------------------------- Why be difficult, when, with just a little more effort, you can be impossible? |
|
From: Jan U. <ja...@ko...> - 2002-09-06 10:42:51
|
Hi!
A little bit work and now the first group.time on-line
meeting summary is up in the forum. You all can reach to
this by following url:
If something seems missing, wrong, right etc., post feedback
to the forum or mailing list.
With regards
Jan Urva aka Sau
|
|
From: Jan U. <ja...@ko...> - 2002-09-06 09:13:09
|
Hi!
The first group.time meeting is over. I was very productive and
informative (at least for me). Now we have somehow clear picture,
what we'll do and where we're going.
I'll thank all the participant and hope, that next time we have
more people in the meeting.
The summary of the meeting will be up in the forum and see ya'll
around. The next meeting will be held in same time (if no conter-
arguments have sent), maybe after week or two weeks..
With regards,
Jan Urva
group.time founder
|
