Menu
▾
▴
rbopensource-developer — List for requests, questions and announcements for the RBOpenSource-Project
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(18) |
Sep
(3) |
Oct
|
Nov
(2) |
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(2) |
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
(5) |
Dec
|
| 2004 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Frank B. <bit...@gs...> - 2004-01-23 13:11:04
|
January 22, 2004 (Frankfurt, Germany) - Frank Bitterlich is proud to
announce the immediate release of XPReceiver 1.0b1, enabling REALbasic
applications to communicate with X-Plane, the popular flight simulator by
Laminar Research.
XPReceiver is an open source class, based on the UDPSocket class, for
REALbasic version 5.x. Using this class, you can create any type of
application that needs to communicate with X-Plane: Navigation software,
flight data recorders, ATC (air traffic control) simulations, multiplayer
systems and more.
It comes with an example application, XPFlightRecorder, that allows you to
record flight data from X-Plane into an Excel-compatible text file. Of
course, XPFlightRecorder is open source, too.
The XPReceiver source is available in the RBOpenSource project at
http://sourceforge.net/projects/rbopensource/
=20
=20
XPReceiver requires REALbasic 5.x (any platform) and X-Plane version 7.30.
It will work with older versions of X-Plane, too, but you need a different
configuration file.
=20
More information, configuration files for older or newer versions of
X-Plane, is available at
http://frankbitterlich.gotdns.com/
=20
How it works
X-Plane offers the option to communicate with other applications (on the
same or another computer, Mac or PC, via LAN or the internet) via UDP.
X-Plane can be set up to send almost every piece of information that is
available, and you can also send data back to X-Plane, changing settings,
manipulating controls, and other things.
With XPReceiver, you can receive and send this information, since XPReceive=
r
is a subclass of RB's UDPSocket control. The nice thing is that once X-Plan=
e
is set up correctly, you even can remotely tell X-Plane which data to send
and which not.
--=20
"Computers in the future may weigh no more than 1.5 tons."
-- Popular Mechanics, forecasting the relentless march
of science, 1949
G=FCnter Schmidt & Co. oHG
Frank Bitterlich eMail: bit...@gs...
Schlosserstr. 4 WWW: http://www.gsco.de/gsco
D-60322 Frankfurt Tel.: 069 / 156809-29
GERMANY Fax: 069 / 156809-28
|
|
From: Frank B. <bit...@gs...> - 2003-11-13 14:47:59
|
Well, not to step on any toes here, but it was created once upon a time for
people who wanted to share some of their work as Open Source contributions
to the RBOpenSource project. As we all know, the number of contributions wa=
s
so overwhelming that somebody else even decided to launch a second RB Open
Source project.
Guys, if you have something to share, please go to the SourceForge project
site and upload your stuff. If you need help in doing that, drop me note
(BTW, I need your SourceForge ID to add you as a developer and release
technician to the project).
SF even has a very sophisticated bug reporting and tracking system we can
use for free. So, if you have something.... PLEASE upload it!
Cheers,
Frank+++
On 12.11.2003 12:19 Uhr, Bruce M. Axtens wrote:
> The core of Pluto is likely slightly more active. I've even forgotten
> what this list is about.
--=20
"Never trust a computer you can't throw out a window."
- Steve Wozniak
G=FCnter Schmidt & Co. oHG
Frank Bitterlich eMail: bit...@gs...
Schlosserstr. 4 WWW: http://www.gsco.de/gsco
D-60322 Frankfurt Tel.: 069 / 156809-29
GERMANY Fax: 069 / 156809-28
|
|
From: Bruce M. A. <bru...@si...> - 2003-11-13 03:51:59
|
The core of Pluto is likely slightly more active. I've even forgotten what this list is about. Bruce. |
|
From: Sascha Ren L. <sas...@we...> - 2003-11-10 17:15:39
|
It is, but it's not very active :-) /sascha On 10.11.2003 15:40 Uhr, Frank Bitterlich shaped the electrons to say: > ... in case this was a test: Yes, this list is alive. :) >=20 > Cheers, > Frank+++ >=20 > On 08.11.2003 9:44 Uhr, Richard T. wrote: >=20 >>=20 >>=20 >>=20 >>=20 >> ------------------------------------------------------- >> This SF.Net email sponsored by: ApacheCon 2003, >> 16-19 November in Las Vegas. Learn firsthand the latest >> developments in Apache, PHP, Perl, XML, Java, MySQL, >> WebDAV, and more! http://www.apachecon.com/ >> _______________________________________________ >> rbopensource-developer mailing list >> rbo...@li... >> https://lists.sourceforge.net/lists/listinfo/rbopensource-developer -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- Sascha Ren=E9 Leib - KOPFteam GmbH - http://www.kopfteam.de/ "Customer support is an art, not a science. But then again, so are other forms of torture." -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- Die KOPFteam GmbH ist Mitglied bei http://www.InPunctoBuch.de/ |
|
From: Frank B. <bit...@gs...> - 2003-11-10 14:40:44
|
... in case this was a test: Yes, this list is alive. :) Cheers, Frank+++ On 08.11.2003 9:44 Uhr, Richard T. wrote: >=20 >=20 >=20 >=20 > ------------------------------------------------------- > This SF.Net email sponsored by: ApacheCon 2003, > 16-19 November in Las Vegas. Learn firsthand the latest > developments in Apache, PHP, Perl, XML, Java, MySQL, > WebDAV, and more! http://www.apachecon.com/ > _______________________________________________ > rbopensource-developer mailing list > rbo...@li... > https://lists.sourceforge.net/lists/listinfo/rbopensource-developer --=20 "When I read a URL on the back of my fortune cookie's fortune, I knew the world would never be the same." -- Anonymous G=FCnter Schmidt & Co. oHG Frank Bitterlich eMail: bit...@gs... Schlosserstr. 4 WWW: http://www.gsco.de/gsco D-60322 Frankfurt Tel.: 069 / 156809-29 GERMANY Fax: 069 / 156809-28 |
|
From: Richard T. <ric...@ho...> - 2003-11-08 08:45:10
|
|
From: Alan B. <rb....@nt...> - 2003-10-24 12:21:51
|
confirm 411614 |
|
From: Frank B. <bit...@gs...> - 2003-06-24 09:32:36
|
Of course there are absolutes. Look for abs() in the language reference. ;) Cheers, Frank+++ On 24.06.2003 11:23 Uhr, Bruce M. Axtens wrote: > >> "There are no absolutes no absolute good or evil; no absolute way of >> living. No absolute truth. All truths are mediated and tempered by the >> fact of living. Being alive qualifies all things." >> Ben Okri in 'A Way of Being Free', 1997, p54 > > How can he say, so absolutely, that there are no absolutes? A bit of > honesty here, Mr Okri, please. At most we can say, "There may be no > absolutes, but seeing as I don't have absolute knowledge I can't be > absolutely sure." > > Bruce. |
|
From: Bruce M. A. <bru...@si...> - 2003-06-24 09:22:38
|
> "There are no absolutes no absolute good or evil; no absolute way of > living. No absolute truth. All truths are mediated and tempered by the > fact of living. Being alive qualifies all things." > Ben Okri in 'A Way of Being Free', 1997, p54 How can he say, so absolutely, that there are no absolutes? A bit of honesty here, Mr Okri, please. At most we can say, "There may be no absolutes, but seeing as I don't have absolute knowledge I can't be absolutely sure." Bruce. |
|
From: Frank B. <bit...@gs...> - 2003-05-16 12:14:55
|
Looks like this one came through :) Cheers, Frank+++ Pedro fp wrote: > = > Cheers, Pedro :-) > = > Web: <http://www.pedro.net.au> PGP Key ID: 387CD96F > Instant messaging... AIM: bandidoOfOz ICQ: 27671678 Jabber: pedrofp > MSN: ma...@pe... Yahoo: pedro_fp= > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > "There are no absolutes no absolute good or evil; no absolute way of > living. No absolute truth. All truths are mediated and tempered by the > fact of living. Being alive qualifies all things." > Ben Okri in 'A Way of Being Free', 1997, p54= > = > ------------------------------------------------------- > Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara > The only event dedicated to issues related to Linux enterprise solution= s > www.enterpriselinuxforum.com > = > _______________________________________________ > rbopensource-developer mailing list > rbo...@li... > https://lists.sourceforge.net/lists/listinfo/rbopensource-developer -- G=FCnter Schmidt & Co. oHG = Frank Bitterlich eMail: bit...@gs... Schlosserstr. 4 WWW: http://www.gsco.de/gsco D-60322 Frankfurt Tel.: 069 / 156809-29 GERMANY Fax: 069 / 156809-28 |
|
From: Pedro fp <li...@pe...> - 2003-05-16 11:24:01
|
Cheers, Pedro :-) Web: <http://www.pedro.net.au> PGP Key ID: 387CD96F Instant messaging... AIM: bandidoOfOz ICQ: 27671678 Jabber: pedrofp MSN: ma...@pe... Yahoo: pedro_fp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "There are no absolutes no absolute good or evil; no absolute way of living. No absolute truth. All truths are mediated and tempered by the fact of living. Being alive qualifies all things." Ben Okri in 'A Way of Being Free', 1997, p54 |
|
From: Frank B. <bit...@gs...> - 2002-11-01 16:37:43
|
Hey, great work! I'll have a look at it over the weekend. Cheers, Frank+++ Fabian Rueger wrote: > = > Hi everyone, > = > I've finally found the time to write up a general recommendation on > how to name variables, objects, etc. in Realbasic. It is based on the > previous mail exchange on this list with a focus on readability of > code. =2E.. -- G=FCnter Schmidt & Co. oHG = Frank Bitterlich eMail: bit...@gs... Schlosserstr. 2-4 WWW: http://www.gsco.de/gsco D-60322 Frankfurt Tel.: 069 / 156809-29 GERMANY Fax: 069 / 156809-28 |
|
From: Fabian R. <fa...@ru...> - 2002-11-01 15:48:18
|
Hi everyone, I've finally found the time to write up a general recommendation on how to name variables, objects, etc. in Realbasic. It is based on the previous mail exchange on this list with a focus on readability of code. I've called this an RFC (request for comment) because that's what it is. Please feel free to send your change proposals via this list, so we can talk them through and (by majority decision or whatever's necessary) agree on a general naming _recommendation_ for RB open source code. Arguably one might want to have stricter conventions, but I set them up pretty liberal, I guess. Please tell me what you think, Yours =46abian PS. I've attached it as an extra text file, and pasted it also in below for your convenience: ---------------------------------------------------------------- -------------------------------------------------------------------------- NAMING RECOMMENDATIONS FOR REALBASIC: 1st Draft (RB-OPENSOURCE RFC 1): =A9Fabian Rueger for RB OpenSource Project at sourceforge.net, November 1, 2002. TABLE OF CONTENTS: 1. Purpose of this document 2. Global vs OOP naming 3. General naming conventions 3.1 Requirements of Code readability 3.2. Lower and uppercase in names 4. Naming conventions 4.1 Globals 4.2 Local Variables 4.3 Class and Instance Names 4.4 Object property, method and function names 4.5 Specific class and OOP names 4.6 Constants 4.6.1 Local and object constants 4.6.2 Global constants ----------------------------------------- 1. Purpose of this document: This document contains recommendations for naming variables, codes, methods and constants in an RB project. For the purpose of this document, all methods, function and variable declarations are considered 'names', and RB programmers are called 'authors'. It is intended not to be a strict set of rules but a recommendation for Open Source authors to enable Open Source projects to interact with each other smoothly by avoiding namespace conflicts of these code declarations. Authors are asked to accept these guidelines for writing reusable code. Within this text, SHOULD resembles a recommendation for naming, COULD/MIGHT an option, while MUST and MUST NOT represent strict requirements for the rest of the guidelines to make sense. This document is not authorized in any way by RealSoftware Inc. ----------------------------------------- 2. Global vs OOP naming Since in any case the best approach for all open source projects is to be as object oriented as possible, any open source code meant to be easily exchangeable between projects should if at all possible avoid requiring global methods, functions or constants. If the code requires globals, their names should be marked by an additional prefix to all other naming conventions. This prefix should be a lowercase g (for 'global'). ----------------------------------------- 3. General naming conventions ----------------------- 3.1 Requirements of Code readability To guarantee the best readability of code, authors should name all code vars and calls best in full wording. RB's autocomplete feature takes away most of the typing work for us, therefore name length is not really an issue. Since BASIC was a language with human readability in mind authors should consider this as strength of the language. Authors MUST NOT abbreviate names and SHOULD choose names best describing the specific function of the code piece to the fullest. Authors SHOULD avoid simplistic names with multiple meanings as name declarations for the sake of more detail (e.g. "AddTwoIntegers" rather than "Add" for a function that adds two integers). ----------------------- 3.2. Lower and uppercase in names Lower and uppercase letters are used to distinguish between words within a name; it is only at the beginning of a name that lower or uppercase letter prefixes should resemble a distinction signal between aspects of code. For readability, longer names containing several words should begin each new word with a capital letter with the exception of the first. The only exception are global constants (c.f 4.6.2). Authors MUST NOT name any properties, methods or names with all-capital letters except global constants. ----------------------------------------- 4. Naming conventions ----------------------- 4.1 Globals All globals should have the prefix 'g' with the exception of global constants (cf. 4.6.2). ----------------------- 4.2 Local Variables In methods and functions, local variables should be rather short than descriptive, to avoid name conflicts. Authors COULD name each function's result as 'result' to have unified return naming conventions. If this is used throughout code, readability is much improved. Authors SHOULD in general use lowercase-only names in local variables. Short names (e.g. x,y,cnt,f) MUST be entirely reserved for local variables. ----------------------- 4.3 Class and Instance Names Each class SHOULD simply end with the term "Object" to signal that it is the class, rather than an instance of it. This allows to have instances of a class that bear the name of the class, without having a name conflict. Objects/instances MUST have a name that is descriptive of their content/use. Authors SHOULD give instances of classes names that begin with a capital letter, to distinguish them from RB's regular variables. Parent/child relationships between classes SHOULD be suggested by at least keeping a part of the super class name in the last part of the child class name. (see 4.5). The word 'Object' as the last part of a name MUST be reserved for classes. Example: Assuming you have a class that contains a list of names, you could call it "NameListObject". This allows for code such as: Dim FirstNameList as NameListObject FirstNameList=3Dnew NameListObject ----------------------- 4.4 Object property, method and function names The above rules apply similarly to methods, functions and properties of a class. Method or function parameters SHOULD especially have descriptive intuitive names. Since RB's tip window displays the name of parameter variables of a function or method, a descriptive name here especially helps to speed up coding. All regular datatypes of RB MUST, as properties or variables, always begin with lowercase letters. Method names SHOULD contain a verb to clearly distinguish them from functions (to signal they alter data, rather than merely reading out data), whereas functions SHOULD be preceded or signaled by similarly appropriate wording like "Get", "Find", etc. Note that both functions and methods SHOULD begin with initial capital letters to clearly distinguish them from regular object properties. Example: A function that returns the square root of an object's properties might be called "GetSquareRoot" instead of just "SquareRoot" to suggest it merely returns a value. Similarly, a method that would set an object's internal properties to such square root should then be called "SetSquareRoot" or "MakeSquareRoot". Example 2: "MoveLeft(horizontalPixels, verticalPixels, speed)" is more descriptive than "MoveLeft(x,y,s)" ----------------------- 4.5 Specific class and OOP names Specific inherent RB subclasses SHOULD be named along the rule that they end with the RB parent class, followed by 'Object' for a class, and nothing but for the instance. Examples: -Window subclasses SHOULD always end with "WindowObject". -Appropriately, window instances SHOULD always end with "Window". -The same would then apply to all objects, e.g., "MySMTPSocket","SMTPSocketObject". Authors COULD additionally name all interface classes with a preceding 'i'. ----------------------- 4.6 Constants Generally, constants should be signaled by a preceding 'k'. This has become convention among most RB programmers. -------------- 4.6.1 Local and object constants =2E..should begin with a 'k', and be followed by a capital letter for readability. Example: kMaxFiles. -------------- 4.6.2 Global constants Authors could either follow the above conventions (4.1 & 4.6) and precede all global constants with a 'gk'; for readability they MIGHT choose to instead use all-capital letters. Example: Instead of using gkPi=3D3.14159 authors MIGHT choose to use PI=3D3.14159 in a global context. -------------------------------------------------------------------------- |
|
From: Ward C. <wa...@jo...> - 2002-09-10 13:15:17
|
Frank wrote ... >I didn't jump in right away since I'd like >the other members of this group to participate a little. I'm watching from time to time, but I don't have time to actively participate until I get past a couple of development milestones. I intend to offer some components at that time to RBOpenSource. -- Ward |
|
From: Sascha L. <sas...@we...> - 2002-09-02 08:24:29
|
> How about a plugin that gives me access to the desktop database especially > the file comments. I would like to be able to set and get. Hm, I think there is some PlugIn already that allowes you to get information from the DesktopDB, but to set, you would need to use AppleScripts. Check out RealSoftware's list of PlugIns, it should be there somewhere.. ______________________________________________________________________________ Die clevere Geldreserve: der DiBa-Privatkredit. Funktioniert wie ein Dispo, ist aber viel gunstiger! Alle Infos: http://diba.web.de/?mc=021104 |
|
From: Bruce M. A. <bru...@si...> - 2002-09-02 06:32:31
|
How about a plugin that gives me access to the desktop database especially the file comments. I would like to be able to set and get. Thanks. Bruce. |
|
From: Frank B. <bit...@gs...> - 2002-08-30 11:58:14
|
Fabian Rueger wrote: > = > Is this list already dead? Just checking... BTW, one of the mroe > interesting issues was that the list mailer refused to accept my > mails until I set up a mail account called mailmaster or some such, > which seems to be part of the SMTP specs. Seems sourceforge is really > keen on sticking to the standards. No mailer I've used elsewhere > required this. Hi Fabian, no it is not dead, but apparently sleeping ;) I guess you are speaking about a Postmaster account... no, that is neither part of the SMTP specs, nor actually required by SourceForge. But it is a de facto standard that every domain with mail exchanger should (must?) have a postmaster acoout - this is where spam complaints etc. usually go to. I'd like to know what happened, since maybe that could be the reason for the "quiteness" on this list. Maybe you want to contact me off-list about this. Now for your other message... I didn't jump in right away since I'd like the other members of this group to participate a little. Anyway... > So, just a question as this thing is slowly developing: How many are = > we now on this list? = The mail list has currrently 26 members. But only three of them are registered as developers. Guys, please remember, even if you have nothing to contribute but a suggestion what the group could develop - speak up! > I was thinking we might need some sort of = > guideline on how we approach open-sourced projects in terms of : > = > - licenses > - documentation (I think it'd be great if we would find some form of = > code documentation standard that reflects RB's ease of use > - source code standard (standardized ways of naming classes, vars, etc)= I agree, although we shouldn't over-regulate it, or make any of the rules mandatory. For stuff we develop and publish under this SourceForge group, we are bound to the LGPL license. But if someone wants to apply a different license to a project (s)he initiates, no problem, there are ways we can do that. = > I'd volunteer to write up a white paper (or is that blue? green?) I suggest to make it white, so we can color it later ;) > for = > this (open to changes comments etc of course) on how the general = > process should work. There've been too many attempts imho on getting = > similar groups off the ground for standardized open RB code, and one = > of the reasons why they failed I think was the lack of proper = > procedures (no, I'm not a fan of bureaucracy, it's just that it helps = > with code). Yup, a starting point would be cool. I suggest as soon as you have something, we publish it on the group, so that everybody can comment on i= t. > To add to this, I'm not a fan of abbreviated variable and property = > names. While naming conventions like "cPoint" might suggest that this = > is a Point class, it makes code reading ugly. I've always thought = > that one of the major advantages of good Basic code is it's = > user-friendly human language. E.g., when I have a class that has a = > property to store ftp-passwords, I won't name that property "psswrd" = > but "FTPpassword", simply because when I read the code again two = > years later, I can immediately see what's going on. I know everybody = > is used to a different system with this, but for joint open source = > projects it's really vital to have a working system, and the more = > explicit it is the better. As a matter of facct, I'm using naming conventions heavily - but I change them too often to be of any use ;) So a guideline or list of suggestions woulld really be good. Personally, I'm a fan of using descriptive names, too; and I like the approach of prefixing local variables and properties with a letter that describes the type. This also helps with the autocomplete feature; if you have an array of strings "listItems", and an integer "listItemCount", autocomplete doesn't help you much. But with "asListItems" and "iListItemCount", you're better off. And I believe in starting class names with Uppercase letters and other variables with lowercase; while RB isn't case sensitive, it healps for readability. But these are just a few suggestions; I guess if you write an outline we would have something to discuss - and keep this list going. Cheers, Frank+++ -- G=FCnter Schmidt & Co. oHG = Frank Bitterlich eMail: bit...@gs... Schlosserstr. 2-4 WWW: http://www.gsco.de/gsco D-60322 Frankfurt Tel.: 069 / 156809-29 GERMANY Fax: 069 / 156809-28 |
|
From: Fabian R. <fa...@ru...> - 2002-08-30 11:29:14
|
Is this list already dead? Just checking... BTW, one of the mroe interesting issues was that the list mailer refused to accept my mails until I set up a mail account called mailmaster or some such, which seems to be part of the SMTP specs. Seems sourceforge is really keen on sticking to the standards. No mailer I've used elsewhere required this. Best, -- Fabian Rueger |
|
From: Fabian R. <fa...@ru...> - 2002-08-26 17:31:56
|
So, just a question as this thing is slowly developing: How many are we now on this list? I was thinking we might need some sort of guideline on how we approach open-sourced projects in terms of : - licenses - documentation (I think it'd be great if we would find some form of code documentation standard that reflects RB's ease of use - source code standard (standardized ways of naming classes, vars, etc) I'd volunteer to write up a white paper (or is that blue? green?) for this (open to changes comments etc of course) on how the general process should work. There've been too many attempts imho on getting similar groups off the ground for standardized open RB code, and one of the reasons why they failed I think was the lack of proper procedures (no, I'm not a fan of bureaucracy, it's just that it helps with code). To add to this, I'm not a fan of abbreviated variable and property names. While naming conventions like "cPoint" might suggest that this is a Point class, it makes code reading ugly. I've always thought that one of the major advantages of good Basic code is it's user-friendly human language. E.g., when I have a class that has a property to store ftp-passwords, I won't name that property "psswrd" but "FTPpassword", simply because when I read the code again two years later, I can immediately see what's going on. I know everybody is used to a different system with this, but for joint open source projects it's really vital to have a working system, and the more explicit it is the better. Comments? -- Fabian Rueger |
|
From: Fabian R. <fa...@ru...> - 2002-08-25 15:29:30
|
Just checking whether this works now... plz ignore >Hi list, > >just to inform you that I'm still trying to get the project's CVS >repository to work, so that we can start to work on the projects. I have >contacted the SF staff ybout an issue I have with the system. > >A short info for those of you submitting projects: If you have a project >you want to have in the CVS, the best way is to export it as XML. Later >for the release, the package can contain anything you want; but the CVS >system can only work correctly with text files. > >Cheers, > Frank+++ > >-- >G=FCnter Schmidt & Co. oHG >Frank Bitterlich eMail: bit...@gs... >Schlosserstr. 2-4 WWW: http://www.gsco.de/gsco >D-60322 Frankfurt Tel.: 069 / 156809-29 >GERMANY Fax: 069 / 156809-28 > > >------------------------------------------------------- >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?rurceforge1&refcode13390 >_______________________________________________ >rbopensource-developer mailing list >rbo...@li... >https://lists.sourceforge.net/lists/listinfo/rbopensource-developer -- =46abian Rueger |
|
From: Frank B. <bit...@gs...> - 2002-08-16 13:11:43
|
Hi list, just to inform you that I'm still trying to get the project's CVS repository to work, so that we can start to work on the projects. I have contacted the SF staff ybout an issue I have with the system. A short info for those of you submitting projects: If you have a project you want to have in the CVS, the best way is to export it as XML. Later for the release, the package can contain anything you want; but the CVS system can only work correctly with text files. Cheers, Frank+++ -- G=FCnter Schmidt & Co. oHG = Frank Bitterlich eMail: bit...@gs... Schlosserstr. 2-4 WWW: http://www.gsco.de/gsco D-60322 Frankfurt Tel.: 069 / 156809-29 GERMANY Fax: 069 / 156809-28 |
|
From: Jan E. <li...@mo...> - 2002-08-16 12:29:36
|
I'm writing an application that needs to be able to send confirmation
emails ... so I looked at some of the available SMTP classes but wasn't
able to find one that was clean and reusable, so I started to write my
own.
Well, it works but ... it lacks error handling since I don't know much
of the SMTP protocol.
So my question is: before reinventing the wheel (I would prefer spending
my time on something else) does anyone know of good, clean, re-usable
SMTP class? It needs to be able to handle 8-bit chars on both Mac and
Windows ... but only text
jem
--
Jan Erik Moström je...@mo... www.mostrom.pp.se
|
|
From: Frank B. <bit...@gs...> - 2002-08-16 10:31:51
|
Hi Ward, I hope you don't mind that I'm posting this on the group's list... As I understand the license issue, the Library GPL and the Lesser GPL are the same thing; I was assuming that we use the latest version of this license anyway, so in a way you could really say we use the "Lesser GPL" instead of the "Library GPL". Quote from the FSF site: > Between version 2 and 2.1, the GNU LGPL was renamed from the GNU Librar= y General > Public License to the GNU Lesser General Public License to better > reflect its actual purpose. = I intended to close the poll about which license to use today, and let the members decide. But so far it looks like the LGPL has won over any other licensing model. As soon as the decision is made, I will post a page that explains the license choice in detail. The idea with the link to the license page is a good one. While we're at it, we need a link collection anyway. = Calling all stations: Please submit suggestions for the link page! "componenst" isn't a typo, it was intended as a test for your reading skills ;) Cheers, Frank+++ Ward Clark wrote: > = > Hi Frank, > = > Thanks for the updated source for WizSockets; it has improvements over > the version that Seth sent to me. > = > I've distracted myself from coding to check into the LGPL and the new > RBOpenSource site, and I have a few comments: > = > 1. At least one person on the NUG thinks that LGPL is the earlier > Library GPL. I assume that you're following the FSF recommendation to > use the newer Lesser GPL. > = > 2. It would be good to provide a link to the LGPL page at the FSF site= =2E > = > 3. "componenst" is a typo on RBOpenSource home page. > = > Additional thanks for getting the RBOpenSource group going. > = > -- Ward -- G=FCnter Schmidt & Co. oHG = Frank Bitterlich eMail: bit...@gs... Schlosserstr. 2-4 WWW: http://www.gsco.de/gsco D-60322 Frankfurt Tel.: 069 / 156809-29 GERMANY Fax: 069 / 156809-28 |
|
From: <sas...@we...> - 2002-08-13 11:25:46
|
Hello again, sorry for the late reply. I was out of the office (and finished up my Text Converter Freeware program :-) OK, sorry, I thought Frank had already moved the rXML archive to the new location. Of course you're welcome to add it to the Sourceforge CVS. Jan Erik Moström wrote: > wir können unser deutch ... exercise (needed as you can see 8-) Hm, is there already a poll on which language we use? So maybe we all opt for some nice "Pidgin English", mixed from words of all our native languages. Don't laugh. That's how me and my wife communicate: Mostly English, with some German, Polish, Finnish, etc. mixed in.We even have some Swedish sayings (like "Pappa betalingar" - probably misspelled, but the pronounciation is just great |-) Greetings /sascha |
|
From: Jan E. <li...@mo...> - 2002-08-12 12:54:29
|
2002-08-12 14:33: Frank Bitterlich <bit...@gs...> is believed to
have typed:
> Darn... sorry, this was meant to go off-list... so all folks except
> Sascha, please ignore ;)
Aber wir können unser deutch ... exercise (needed as you can see 8-)
jem
--
Jan Erik Moström je...@mo... www.mostrom.pp.se
|
