Menu
▾
▴
curl-email-news — News, Discussions, .. about curlMail
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(16) |
Nov
(4) |
Dec
(6) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
|
Feb
|
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: David G. <da...@cu...> - 2002-03-08 12:02:38
|
Thanks Gene. We're very enthusiastic about the changes (and the money). This move was a strong show of support from our investors. Tom Stiling, the new president, has a lot of experience running companies of our size. I'm looking forward to what the next year will bring. -- Dave |--------+-------------------------------------------> | | gh...@nc... | | | Sent by: | | | cur...@li...urc| | | eforge.net | | | | | | | | | 03/07/2002 09:11 PM | | | | |--------+-------------------------------------------> >------------------------------------------------------------------------------------------------------------------------| | | | To: cur...@li... | | cc: | | Subject: [curl-email-news] Macromedia Flash MX | >------------------------------------------------------------------------------------------------------------------------| Just noticed that Macromedia is releasing a major upgrade for their Flash product called Flash MX. They're talking rich client experiences and building user interfaces. I suppose it is a logical step for them. It looks to me like it costs $499 to buy what you need to develop with this product. This cnn link is a couple days old but may still work. http://www.cnn.com/2002/TECH/ptech/03/05/flash.overhaul.idg/inde x.html Of course there are tons of stuff on the Macromedia web site. http://www.macromedia.com/ Was pleased to see that Curl just got $7 million and had a major shakeup of its board and top management with the emphasis to be on making Curl "ubiquitous in the Web community." Let's hope they can do it. Much Cheers, Gene _______________________________________________ curl-email-news mailing list cur...@li... https://lists.sourceforge.net/lists/listinfo/curl-email-news |
|
From: <gh...@nc...> - 2002-03-08 00:57:34
|
Just noticed that Macromedia is releasing a major upgrade for their Flash product called Flash MX. They're talking rich client experiences and building user interfaces. I suppose it is a logical step for them. It looks to me like it costs $499 to buy what you need to develop with this product. This cnn link is a couple days old but may still work. http://www.cnn.com/2002/TECH/ptech/03/05/flash.overhaul.idg/inde x.html Of course there are tons of stuff on the Macromedia web site. http://www.macromedia.com/ Was pleased to see that Curl just got $7 million and had a major shakeup of its board and top management with the emphasis to be on making Curl "ubiquitous in the Web community." Let's hope they can do it. Much Cheers, Gene |
|
From: F M. <mu...@co...> - 2001-12-18 12:48:23
|
Hi all, I don't think that it's necessary to announce every commitment, but I changed a little bit the structure and therefore some files have disappeared in subfolders and a project file was added. Just that you know, if you get some missing file attributes. The code hasn't changed dramatically but one can see what's going on: 1) if a profile for an IMAP server is set then the server is connected once. To try another server, change your profile and reload the applet. 2) to send an email change the mail-server in the profile, compose a new message, connect to the server, see what happens and send the email. The connections isn't closed. This might cause problems when sending several mails. Note, that the server doesn't take a proper account name as the protocol doesn't allow authentication. I hope that all the limitations will encourage people to improve the applet. Merry Christmas, Friedger Friedger Mueffke - University of Bristol http://www.cs.bris.ac.uk/~muffke - mu...@cs... |
|
From: Brent Y. <br...@cu...> - 2001-12-17 17:14:42
|
Chris Banford wrote: > I can also put a News bulletin on the December curlBreaker.com issue, so > people can try it out. As well as a highlight on curlexamples.com. If it isn't already submitted as a hyperlinked example like the chess game and klondike card games are, then someone should submit it as a link so that others can find it easier. Also - as a side note, I submitted a request to sourceforge a long, long time ago to add curl as a programming language option and, oddly enough, today received an "update" to the request where the priority was changed to 1 - so we'll see. Cheers, Brent -- ------------------------ Brent A. Young Software Engineer, Technology Evangelist Curl Corporation (W) 415-625-5148 (F) 415-625-5142 Tri hard |
|
From: Chris B. <ch...@bs...> - 2001-12-17 16:54:54
|
> > Hey Friedger, > > I'm not sure the email client qualifies for the coding contest. However, if > you want publicity, we may be able to put a link to the project up on the > Curl developers home page. Let me know if you want me to look into that. I can also put a News bulletin on the December curlBreaker.com issue, so people can try it out. I haven't looked at the email project for a while (guilty as charged), as I've been so deep under, that I've been breathing with a straw! Do you have curlMail to the point where it will send and recieve mails properly? > Also, I don't think Chris would mind if you sent a message out to the > curlbreaker list asking if people want to help out. Don't ask me for permission! Please use it to promote Curl (projects) in any way possible. > Glad to hear you've made some progress on the code. Me too. I'm hoping to be able to contribute a bit sometime in the not to distant future (Friedger, if you need a Tree control, I can send you the one I've built -- it might make a good basis for a 'Preferences' dialog box). -Chris |
|
From: David G. <da...@cu...> - 2001-12-17 13:45:40
|
Hey Friedger, I'm not sure the email client qualifies for the coding contest. However, if you want publicity, we may be able to put a link to the project up on the Curl developers home page. Let me know if you want me to look into that. Also, I don't think Chris would mind if you sent a message out to the curlbreaker list asking if people want to help out. Glad to hear you've made some progress on the code. -- Dave |--------+-------------------------------------------> | | F Muffke | | | <mu...@co...> | | | Sent by: | | | cur...@li...urc| | | eforge.net | | | | | | | | | 12/17/2001 07:41 AM | | | | |--------+-------------------------------------------> >------------------------------------------------------------------------------------------------------------------------| | | | To: cur...@li... | | cc: | | Subject: [curl-email-news] Packaging & Competition | >------------------------------------------------------------------------------------------------------------------------| Hi everybody, I tried to give some structure to the file collection. If anybody changed anything lately, it would be good to commit the changes now. Do you think we could release a first version as an entry for the competition? Just to win publicity, not money as members of Curl Corp. have done most of the work. Friedger Friedger Mueffke - University of Bristol http://www.cs.bris.ac.uk/~muffke - mu...@cs... _______________________________________________ curl-email-news mailing list cur...@li... https://lists.sourceforge.net/lists/listinfo/curl-email-news |
|
From: F M. <mu...@co...> - 2001-12-17 12:42:21
|
Hi everybody, I tried to give some structure to the file collection. If anybody changed anything lately, it would be good to commit the changes now. Do you think we could release a first version as an entry for the competition? Just to win publicity, not money as members of Curl Corp. have done most of the work. Friedger Friedger Mueffke - University of Bristol http://www.cs.bris.ac.uk/~muffke - mu...@cs... |
|
From: F M. <mu...@co...> - 2001-12-17 12:18:14
|
Hi everybody, I tried to give some structure to the file collection. If anybody changed anything lately, it would be good to commit the changes now. Do you think we could release a first version as an entry for the competition? Just to win publicity, not money as members of Curl Corp. have done most of the work. Friedger Friedger Mueffke - University of Bristol http://www.cs.bris.ac.uk/~muffke - mu...@cs... |
|
From: <gh...@nc...> - 2001-11-03 03:52:27
|
On 2 Nov 2001, at 8:15, Dan Breslau wrote: > I'm very interested to know what sort of design tools > you're looking for: Visual design tools (like PB), or > class design tools (like Rational Rose), existing > code packages (and if so, what kinds?), or something > completely different. Not that I can promise to > provide it immediately, of course :-) > I wasn't thinking in terms of design tools but more in terms of design guidelines and recommendations. Here is the line of thinking that this question grew out of. When I finished my first PB app I was extremely pleased and proud and it did everything that it was supposed to do. However, if I had been able to look back on it two years later I would have seen newbie written all over it. PB is an extensive and robust language and there are almost always multiple ways to implement any specific functionality. After working with the product daily for months and years you acquire a repertoire of techniques that have proven to be good ways to do certain things. These may have come from trial and error or they may have come from books, PB's classes, web sites, etc. If you are new to the tool, most of the techniques you come up with will not end up in the best practices manual. I would be so bold as to assert that everything stated in the previous paragraph applies to Curl too. However, we're kind of short on people with years of experience with Curl. I think I was fishing for two things when I asked my question about resources that would assist our design. One is sample code for implementing various functionality that is commonly found in Windows apps. I'm thinking here not only in terms of code attached to individual objects but also to how many levels of inheritance make sense to do certain things and what kinds of things you do at which levels in various object hierarchies. The other thing that I was hoping for was some fairly specific big picture guidelines for organizing a sizable Curl project. What has been proven to work well for splitting functionality amongst various packages and multiple developers. I've been digging through the code on the Curl web site and on curlexamples.com and these are certainly a big help. Perhaps it is too early in the evolution of Curl to come up with any kind of a best practices manual but I thought I would ask the question with the hope that we could avoid as many pitfalls as possible. Gene |
|
From: Dan B. <dbr...@wo...> - 2001-11-02 13:15:33
|
> A question for Dan if you're lurking out there. Are there any materials that > have been developed for the official Curl training classes (or used with > Siemens) that could be useful to and made available to the curlmail team. > They wouldn't have to be in a pretty package--just something that > developers could cope with. I'm thinking of anything that would assist in > coming up with a better design up front. I'm pretty sure that anything that we might have would already be available on our web site (under "Developers"). There isn't much there now, alas. I'm very interested to know what sort of design tools you're looking for: Visual design tools (like PB), or class design tools (like Rational Rose), existing code packages (and if so, what kinds?), or something completely different. Not that I can promise to provide it immediately, of course :-) Perhaps Brent has other thoughts on this; I know he reads this sometimes too. -- Dan |
|
From: <gh...@nc...> - 2001-11-01 23:38:35
|
A couple weeks back I checked on Amazon and the Early Adopter Curl book was listed at full price. Just checked this afternoon and saw it was discounted $10. A question for Dan if you're lurking out there. Are there any materials that have been developed for the official Curl training classes (or used with Siemens) that could be useful to and made available to the curlmail team. They wouldn't have to be in a pretty package--just something that developers could cope with. I'm thinking of anything that would assist in coming up with a better design up front. My first PowerBuilder app did what it was supposed to do but was clearly the work of someone with very limited experience with the tool. I'm just thinking it could be a real assest to have the benefit of as much experience as possible as early as possible. Gene |
|
From: <gh...@nc...> - 2001-11-01 01:02:27
|
If you haven't found it yet, take a look at the Utility Classes on the curl web site. It is under the framework extensions tab on the developer's page. What especially caught my eye was the button requestor code. There is some simple, elegant code here that looks to be very useful in building a ui under windows. It illustrates how to deal with windows events such as when a user closes the window that an object is on. There is a nice usage of an anonymous procudure there. While poking around there I discovered the curl output procedure that looks to be handy for debugging. The callback manager looked interesting too but at this point I'm not sure what it is good for. Are the socket tools used to handle communications stuff in the curlmail applet? gene |
|
From: Brent Y. <br...@cu...> - 2001-10-30 03:31:39
|
gh...@nc... wrote: > Now if you had a few thousand lines of code and needed to change > all your VBoxes Brent's idea would be extremely appealing. But, if > I'm planning ahead I still like the idea of a common superclass. definitely. I'd recommend going ahead full steam with your thoughts on this - the dynamic reassignment of what "vbox" means is very cool but not very useful in this case. Cheer,s Brent > > > In practice (with PB) most foundation class objects are abstract > classes and this is easily enforced in Curl if desired. The general > rule in PB was that all objects of type X should have a common > ancestor that you can apply changes to. > > There is no good reason to insist that because something was the > best solution in PB it is also the best soution in Curl. If there is a > better way to do it in Curl let's find it. I still think the foundation > class paradigm is a good "first approach" for setting up our class > libraries. > > Best Regards, > Gene > > > _______________________________________________ > curl-email-news mailing list > cur...@li... > https://lists.sourceforge.net/lists/listinfo/curl-email-news -- ------------------------ Brent A. Young Technology Evangelist Curl Corporation (W) 415.625.5148 (F) 415.625.5142 Tri hard |
|
From: <gh...@nc...> - 2001-10-30 02:46:26
|
On 29 Oct 2001, at 6:21, Brent Young wrote:
> Hello all -
>
>...
> Instead of having a package which you import which defines all of your
> MyVBox and MyCommandButton overrides, why not just define VBox and
> CommandButton to do what you want in the first place - this way you can
> actually have different "styles" in different packages.
>
> Try this to see what I mean:
>
> --------------------------------------------------------------
> {import * from CURL.GUI.BASE}
>
> {define-class VBox {inherits CURL.GUI.BASE.VBox}
> {constructor {default ...}
> {construct-super ..., color = "blue"}
> }
> }
>
> {VBox "this is blue", "because it's my vbox"}
> -------------------------------------------------------------
>
> So without changing any existing code, you can instantly redefine what
> the objects do simply by importing a package which contains the above
> definition. (i think).
>
>
> Cheers,
> Brent
>
This is very cool and definitely works as advertised. Never woulda'
thought you could create an object with the same name like that.
My thoughts are that if something is not a 100% true VBox it might
be better if it had a different name. If VBox acts different in different
source files I would think it would be kinda' suprising at times.
(Oh, THAT VBox!) If you want to apply the same change to all
VBoxes in your system and VBox is defined differently in different
places you have to make the change in all those places. If instead
the VBoxes that are defined in various source files are derived from
a single foundation class you would have the option of changing all
VBoxes in the system or changing all VBoxes in any file by
changing code in only one place.
Now if you had a few thousand lines of code and needed to change
all your VBoxes Brent's idea would be extremely appealing. But, if
I'm planning ahead I still like the idea of a common superclass.
In practice (with PB) most foundation class objects are abstract
classes and this is easily enforced in Curl if desired. The general
rule in PB was that all objects of type X should have a common
ancestor that you can apply changes to.
There is no good reason to insist that because something was the
best solution in PB it is also the best soution in Curl. If there is a
better way to do it in Curl let's find it. I still think the foundation
class paradigm is a good "first approach" for setting up our class
libraries.
Best Regards,
Gene
|
|
From: Brent Y. <br...@cu...> - 2001-10-29 14:21:43
|
Hello all -
You may want to think about just redefining what you want the different
objects/text-formats to do ... w/o defining subclasses of different
names. I just fixed something I was trying to figure out w/ the help of
dbreslau and others at curl and this seems like it'd work fine and would
be applied nicely here, unless I'm missing something.
Instead of having a package which you import which defines all of your
MyVBox and MyCommandButton overrides, why not just define VBox and
CommandButton to do what you want in the first place - this way you can
actually have different "styles" in different packages.
Try this to see what I mean:
--------------------------------------------------------------
{import * from CURL.GUI.BASE}
{define-class VBox {inherits CURL.GUI.BASE.VBox}
{constructor {default ...}
{construct-super ..., color = "blue"}
}
}
{VBox "this is blue", "because it's my vbox"}
-------------------------------------------------------------
So without changing any existing code, you can instantly redefine what
the objects do simply by importing a package which contains the above
definition. (i think).
Cheers,
Brent
gh...@nc... wrote:
> I'm happy to report that I am now in a position to put together a
> working foundation class library fairly quickly. I would be
> embarassed to say how long it took me to get this far but suffice it
> to say that it has been a very good learning experience. There was
> a bit of a learning curve to working with code in packages.
>
> In this post I want to explain what I propose to do and ask for
> comments to see if there is a consensus on it and related issues.
>
> Ok, let's start with some sample foundation class library code.
> Here is the current Foundation.curl.
> ------------------------------------------------------------------
> ||foundation class for curl-email project
> {curl 1.6 package}
> {package ORG.CURL-EMAIL.FOUNDATION,
> author="",
> version="0.1"}
>
> {import * from CURL.GUI.BASE}
> {import * from CURL.GUI.CONTROL-BASE}
> {import * from CURL.GUI.CONTROLS}
> {import * from CURL.GUI.EXTRAS}
> {import * from CURL.GUI.SINGLETON}
> {import * from CURL.GUI.STANDARD}
> {import * from CURL.GUI.TEXT-EDIT}
> {import * from CURL.GUI.TEXT-FORMATS}
>
> {define-class public MyVBox {inherits VBox}
> {constructor public {default ...}
> {construct-super ...}
> }
> }
>
> {define-proc public {my-vbox ...}:MyVBox
> {return {MyVBox ...}}
> }
>
> {define-class public MyHBox {inherits HBox}
> {constructor public {default ...}
> {construct-super ...}
> }
> }
>
> {define-proc public {my-hbox ...}:MyHBox
> {return {MyHBox ...}}
> }
>
> {define-class public MyCommandButton {inherits
> CommandButton}
> {constructor public {default ...}
> {construct-super ...}
> }
> }
>
> {define-proc public {my-commandbutton
> ...}:MyCommandButton
> {return {MyCommandButton ...}}
> }
>
> {define-class public MyTextField {inherits
> TextField}
> {constructor public {default ...}
> {construct-super ...}
> }
> }
>
> {define-proc public {my-textfield
> ...}:MyTextField
> {return {MyTextField ...}}
> }
> ------------------------------------
> This is largely based on examples from the curl
> basic docs for using rest arguments and the curl
> gui docs for building custom controls.
>
> Here is code that exercises the package above.
> -------------------------------------------
> {curl 1.6 applet}
> {import * from ORG.CURL-EMAIL.FOUNDATION,
> location="file:///c:/cvs/curlmail/curl-
> email/Foundation.curl"}
>
> {value
> {MyVBox "test", background="pink", font-size=14}
> }
>
> {value
> {my-vbox "test", background="yellow", font-
> size=14}
> }
>
> {value
> h:MyHBox = {my-hbox
> background="blue"}b:MyCommandButton = {my-
> commandbutton}
> {h.add b}
> {h.add {my-commandbutton}}
> {h.add {my-textfield width=3in}}
> }
> -----------------------------------------
> (some of the code lines probably got wrapped in
> odd places but hopefully the intent is clear)
>
> I suppose it is obvious that these rasise a
> swarm of questions/issues.
>
> I have worked with vendor supplied class
> libraries prior to curl and one of the golden
> rules that I have accepted is that you never
> create an object in code that inherits directly
> from a vendor library object. Instead all
> objects inherit from your own objects in your
> own libraries. Hence the idea of a foundation
> class library that holds all your lowest level
> objects that inherit directly from vendor
> library objects. The result is that you can
> make global changes in any of your objects by
> changing the corresponding ancestor object in
> your foundation class.
>
> So with the sample code above, instead of having
> VBox objects throughout your code you would have
> MyVBox objects. I've seen the advantages of
> doing this on some fairly large projects and it
> is hard to contemplate the alternative.
> Ultimately you would probably have several other
> objects in a UI package that inherit from MyVBox.
>
> You have probably read Dan Breslau's post where
> he suggests that the golden rule cited above may
> not be warranted and for sure suggests that
> objects should be named according to their
> function. My intent here is to get a feel how
> the rest of the team thinks on these issues and
> not to suggest that mine is the only way to go.
>
> I am new to programming in curl and suspect most
> of the team are relatively new to it too. My
> experience with this type of situation is that
> about the time we get the project finished is
> when we'll know how we wish we had done it from
> the beginning. Having a foundation class object
> underneath all our objects will give us the
> chance to go in and do some of the things we
> wished we had done in the beginning with the
> least amount of effort.
>
> The base class objects are the most generic
> objects of a given type that we will have. In
> the spirit of giving them descriptive names we
> could use GenericVBox instead of MyVBox or maybe
> GenVBox. I am personally not fussy about the
> exact name buy do prefer something rather short
> and consistent. Note in the package code above
> I have written a function for each class that
> returns an object of the given class. This
> would add a layer of indirection that may prove
> valuable and I like it because the curl naming
> conventions mean that function names are all
> lower case. So whether to create all objects
> through a function, directly from the class
> name, or a mix of the two is a related question.
>
> Finally a few smaller questions to think about.
> The location specifier in the package
> declaration above is specific to my computer so
> we need to find a way to deal with that.
> And how about author and version in the package
> declaration. Are we going to use our own names
> or a team name and what version to use for now?
> And what about the file name Foundation.curl?
> Do we want to think about standards for file
> names and indentifier names? Also points of
> style such as spaces around assignment
> operators, etc.
>
> I'm ready to move quickly on building a
> foundation class which for starters would hold
> all the visual GUI classes that I can come up
> with. Foundation classes can also be valuable
> for non-visual objects but it depends a lot on
> what you're doing with them.
>
> Your comments are requested and appreciated.
>
> Gene H.
>
> _______________________________________________
> curl-email-news mailing list
> cur...@li...
> https://lists.sourceforge.net/lists/listinfo/curl-email-news
--
------------------------
Brent A. Young
Technology Evangelist
Curl Corporation
(W) 415.625.5148
(F) 415.625.5142
Tri hard
|
|
From: Dan B. <dbr...@wo...> - 2001-10-29 02:21:04
|
gh...@nc... wrote: > In PB we used inheritance extensively with transaction objects that > handled database details and custom objects which implemented > various specialized processing that could not be done with > standard objects. An example might be inplementing a spell > check feature that picks up errors as you type. I don't know > enough about Curl at this point to suggest anything more specific > but inheritance can definitely be useful with non-visual objects. One example is the IMAP classes in the email client; there are a couple of non-visual inheritance hierarchies there. > I don't know of any compelling reason to use a function call to > instantiate objects. One reason I put those in my example > package was that I was extremely pleased that I got them to work. > Before I figured out that I had to give the constructor public access, > the only way I could create the objects defined in the package was > to use the function call method. If you build the constructor (of a > class defined in a package) with package visibility you can force > any creation of the object outside of the package to go through a > public access function which I thought was rather cool. Note that Curl provides class factories, which may eliminate the need for creating separate creation procs. For example, you may have a single concrete class at one point in your development. Later, you may decide that you need some derived classes. Putting a factory in the base class can allow it to return one of the derived class objects when you need to instantiate one. (The TextFlowBox classes do this, by the way.) This isn't always the right approach, because it assumes you can update the base class code when you add a derived class, and this isn't always the case. (You can't add another class derived from TextFlowBox and get the factory to return it.) -- Dan |
|
From: <gh...@nc...> - 2001-10-28 16:52:53
|
Will try here to pick up any loose end I did not get to last night. I would feel better if whatever we use for our own naming conventions follows the Curl naming guidelines. You can bet that anyone that goes to the official Curl training will be taught to use them and all the official Curl docs and examples will follow the Curl guidelines. As early adopters people will look to us to set standards in this and other areas. The naming guidelines seemed rather odd to me at first but they are starting to feel more normal and I have to believe that whoever came up with them has a better overview of things than I do. Initial versioin of 0.1 sounds great to me. If you have a strong preference for ORG.CURLMAIL.XXX for package names I will go along but ORG.CURL-MAIL.XXX allows us to stick with the naming guidelines. Dan suggested ORG.CURL- EMAIL.XXX which would also be good. I'm good with spaces around assignments and most other operators so let's plan on that. In PB we used inheritance extensively with transaction objects that handled database details and custom objects which implemented various specialized processing that could not be done with standard objects. An example might be inplementing a spell check feature that picks up errors as you type. I don't know enough about Curl at this point to suggest anything more specific but inheritance can definitely be useful with non-visual objects. I don't know of any compelling reason to use a function call to instantiate objects. One reason I put those in my example package was that I was extremely pleased that I got them to work. Before I figured out that I had to give the constructor public access, the only way I could create the objects defined in the package was to use the function call method. If you build the constructor (of a class defined in a package) with package visibility you can force any creation of the object outside of the package to go through a public access function which I thought was rather cool. As per Dan's suggestion I was able to remove the path from the location spec in the import statement I used and all still works. Just keep the package in the same place as the code that imports it or use a relataive path and we should be ok. I like the ideas of using our own names in the internal documention of files. Since we're not getting paid at least we can get a little glory. I agree with Chris on having good internal docs at the top of each file. I don't especially enjoy doing it but it really helps and, again, we will be setting an example that others will be looking at. I say let's take what Chris sent and use that everywhere. I think we're very close to having a consensus on how to move forward. If I can get some further feedback on package names, where/when/what to use to prefix class names and thoughts about sticking to naming guidelines that should about tidy things up. I will then write up what I think is our consensus is and send that out for final comments. I'm anxious to get a design and start coding, but at the same time the more we learn about working with Curl before we start coding, the better the final product is likely to be. I think it is pretty much a given that we will change the design and/or implementation a lot as we learn more about working with Curl. I see the Curl email project as a chance to create a really compelling app that will be the first exposure to this technology for many people and a significant step towards being able to go to monster.com and finding big lists of jobs available after doing a search on "curl". I've got cable modem at home and when I use hotmail.com it is still frustratingly slow and clunky to do anything there. The potential impact of this project is huge. I'm open to writing an article for curlbreaker but feel I need to learn a good bit more before I start telling other people how to do it. Gene |
|
From: Gene H. <gh...@nc...> - 2001-10-28 01:57:00
|
Thanks everyone for the encouraging words on my last post. Sorry it took a while to respond but I figure this will at least be waiting 1st thing Sunday where most of y'all are. This will be a mix of responses to the feedback from Chris and Friedger. By the way is everyone else getting two copies of every post or is there something weird in my setup that's causing it? Based on your feedback I conclude that we do want to have at least one of our own classes underneath all the objects in the curlmail applet. I hope you'll excuse me for referring back to PowerBuilder (PB) from time to time. It really has many parallels to Curl. Of course it is very different too. Both are used to produce programs that run in Windows. PB runs on the desktop and is used to produce client/server apps. Curl runs in the browser and produces a rather different breed of client/server apps. Both have a complete OO programming language. PB has a whole set of UI and other objects that you use to build apps. PB has objects that handle events. PB supports private, protected, public and class variables. You may not know it, but there are a huge amount of PB apps out there that are getting rather dated but have not been replaced because of all the things that (until Curl) you can't do in the browser. Once Curl gets critical mass I think the demand to replace these PB apps will be enormous. After many years, tens (if not hundreds) of thousands of projects and millions of man hours with PB the proven best practice was to always use a foundation class. It was typical for most objects to have 1-4 layers of inheritance in them. I would start getting antsy about performance with 5 or more layers but the advantages of OO design were considered to far outweigh any performance penalties unless you had a really excessive number of levels of inheritance. It was generally the stuff your objects were doing (like hitting the database) that had the big performance penalties. The PB runtime system was very good at dynamically assembling objects and I suspect Curl is too. I can tell you that changing a few ancestor objects and seeing the result propagated throughout you app is extremely awesome. When I was talking about a naming convention for objects I was mostly thinking in terms of foundation class objects (I tend to refer to these as base class objects too) which are the first level of inheritance off the Curl library objects. By definition these are the most generic objects that you have. Once you start creating objects off of these, you are usually thinking in terms of creating some very specific functionality. What I'm working up to is that it is more natural to name 2nd level and above objects based on functionality. I don't know of any big advantages to having the same prefix stuck on every object in the system. With PB I don't recall any reason to find every object in the app. Usually you are interested in one or a few specific objects at a time. As long as you are reasonably aware of Curl object names, name clashes are unlikely. I am not strongly opposed to the same prefix on all objects if that is what you guys want but would like to toss out a couple alternatives before it becomes final. One option that could be useful is to use a different prefix based on what package an object is in. With this the prefix might be "UIBase" for UI foundation class objects and "UI" for other UI objects. This makes it easy for someone new to the project to track down the source of any object they encounter. Another option is to drop the prefix altogether once you're above the base class and rely soley on a descriptive name. I don't kown of any problems that this would cause. In PB we put foundation class objects in their own library (equivalent to package in Curl) and I'm thinking we would do the same. We would have one such package for visual gui objects and gather that we have something that is roughly equivalent for a lot of the communications stuff. If we find a need for more types of base classes we can create appropriate packages. I have more to write but it is getting late here so will take up where I left off tomorrow. Best Regards, Gene |
|
From: F M. <mu...@co...> - 2001-10-26 13:40:14
|
Hi, > I agree with you on this. Indirection is one of the fundementals of OOP, and > every time I 'skip' doing this type of layering, it comes back to haunt me > (sooner or later). I'm not well enough qualified to say anything about the practical aspects of OO. However, I think it can't be too wrong. The only concern would be performance. Does it make any difference to subclass everything (at least the GUI-elements)? > > Having a foundation class object > > underneath all our objects will give us the > > chance to go in and do some of the things we > > wished we had done in the beginning with the > > least amount of effort. Sounds reasonable, although Dan questions if it is necessary. I remember to have heard something about general layouts for GUI-elements that can be defined and changed globally. Something like the ControlUIs. Is that right? > CMailVBox > or > CM-VBox I would go for CMVBox or VBoxCM. > I would be happy with ORG.CURLMAIL.xxx Me too. > For the versioning numbers, I propose to use the Unix system that Open > Source projects seem to prefer. So "0.1" would be a good place to start. We > just need to figure out what we want to achieve for the "0.1" release :) > I'll provide t-files for the three basic protocols. > > And what about the file name Foundation.curl? > > Do we want to think about standards for file > > names and indentifier names? Also points of > > style such as spaces around assignment > > operators, etc. > > How about prefixing our project Classes and Procs with 'CM-' and 'cm-' > respectively? Do you mean the file names? That's too much I guess. I'd suggest capital letter in the filenames, subdirectories in lowercases. > > I Very much vote for using spaces around the '=' -- I personally find it > quite tough to wade through long assignments where everything is squished > together Hopefully, there will be an add-on for the IDE that will do the layout for me, more than only indenting. > > I'm ready to move quickly on building a > > foundation class which for starters would hold > > all the visual GUI classes that I can come up > > with. Foundation classes can also be valuable > > for non-visual objects but it depends a lot on > > what you're doing with them. What kind of non-visual object were you think of? String, Timer, Socket.....? The AsyncClientConnection would be our foundation class for the socket. Or should I say CMAsyncClientConnnection. I'm confused! >:- | When shall we use the prefix? Only if it is a subclass with the same name? Should I introduce CMSocket to the connection class? > Don't let us slow you down Gene! Go ahead! I'm looking forward to seeing a first layout of the user interface. Friedger -- Friedger Mueffke - University of Bristol http://www.cs.bris.ac.uk/~muffke - mu...@cs... |
|
From: Chris B. <ch...@bs...> - 2001-10-26 12:29:39
|
Hi Gene,
Great mail! Very motivating to see one of our fledgling group grabbing the
bull by the horns.
What you have written below is very informative, and extremely well written
-- great explanations of WHY you propose doing things a certain way.
I've plonked my feedback throughout...
----------
>From: gh...@nc...
>
> I suppose it is obvious that these rasise a
> swarm of questions/issues.
Not that many from my standpoint, actually...
> I have worked with vendor supplied class
> libraries prior to curl and one of the golden
> rules that I have accepted is that you never
> create an object in code that inherits directly
> from a vendor library object. Instead all
> objects inherit from your own objects in your
> own libraries. Hence the idea of a foundation
> class library that holds all your lowest level
> objects that inherit directly from vendor
> library objects. The result is that you can
> make global changes in any of your objects by
> changing the corresponding ancestor object in
> your foundation class.
I agree with you on this. Indirection is one of the fundementals of OOP, and
every time I 'skip' doing this type of layering, it comes back to haunt me
(sooner or later).
> So with the sample code above, instead of having
> VBox objects throughout your code you would have
> MyVBox objects. I've seen the advantages of
> doing this on some fairly large projects and it
> is hard to contemplate the alternative.
> Ultimately you would probably have several other
> objects in a UI package that inherit from MyVBox.
>
> You have probably read Dan Breslau's post where
> he suggests that the golden rule cited above may
> not be warranted and for sure suggests that
> objects should be named according to their
> function. My intent here is to get a feel how
> the rest of the team thinks on these issues and
> not to suggest that mine is the only way to go.
>
> I am new to programming in curl and suspect most
> of the team are relatively new to it too.
I'm afraid the only Curl gurus on our team are those that work at Curl corp.
I'm looking forward to changing this fact though :)
> My experience with this type of situation is that
> about the time we get the project finished is
> when we'll know how we wish we had done it from
> the beginning.
:)
> Having a foundation class object
> underneath all our objects will give us the
> chance to go in and do some of the things we
> wished we had done in the beginning with the
> least amount of effort.
>
> The base class objects are the most generic
> objects of a given type that we will have. In
> the spirit of giving them descriptive names we
> could use GenericVBox instead of MyVBox or maybe
> GenVBox. I am personally not fussy about the
> exact name buy do prefer something rather short
> and consistent.
I don't think any of us will to set on any naming rule. I'll suggest using a
short prefix that pertains to curlMail:
CMailVBox
or
CM-VBox
I know that the second breaks the 'official' Curl naming conventions, by
using a '-', but it is short, and will make our project's classes quick and
easy to spot.
> Note in the package code above
> I have written a function for each class that
> returns an object of the given class. This
> would add a layer of indirection that may prove
> valuable and I like it because the curl naming
> conventions mean that function names are all
> lower case. So whether to create all objects
> through a function, directly from the class
> name, or a mix of the two is a related question.
You've got me there! Do you have a concrete reason for the extra
indirection, or is it just a 'gut' feeling from previous experience?
> Finally a few smaller questions to think about.
> The location specifier in the package
> declaration above is specific to my computer so
> we need to find a way to deal with that.
I would be happy with ORG.CURLMAIL.xxx
That should keep us from colliding with other package names, and it's not
too long.
> And how about author and version in the package
> declaration. Are we going to use our own names
> or a team name and what version to use for now?
I like the idea of having the creator of the file adding their name as the
"author". This will make it easier to ask questions in the future.
I would like to see us use a standard set of comments at the top of each
curlMail file, where other member who have worked on a file can add their
names. Notes about the change/bug fix history might also be called for. At
some point Curl corp. will be releasing the hooks for the CurlDoc generator
(like the API docs), and it would be nice to have the infos already in
comments, so we can migrate easily to this inthe future.
Here are some ideas off the top of my (sleepy -- still feels early to me)
head for this file 'comments' header:
Creation Date:
Modification Date:
Project Name:
Workers: (those who have actually worked on this file)
Explanation:
Notes:
Version History:
Known Bugs:
ToDo:
For the versioning numbers, I propose to use the Unix system that Open
Source projects seem to prefer. So "0.1" would be a good place to start. We
just need to figure out what we want to achieve for the "0.1" release :)
> And what about the file name Foundation.curl?
> Do we want to think about standards for file
> names and indentifier names? Also points of
> style such as spaces around assignment
> operators, etc.
How about prefixing our project Classes and Procs with 'CM-' and 'cm-'
respectively?
I Very much vote for using spaces around the '=' -- I personally find it
quite tough to wade through long assignments where everything is squished
together
Use this: set a-box.width = 200px
not this: set a-box.width=200px
> I'm ready to move quickly on building a
> foundation class which for starters would hold
> all the visual GUI classes that I can come up
> with. Foundation classes can also be valuable
> for non-visual objects but it depends a lot on
> what you're doing with them.
>
> Your comments are requested and appreciated.
>
> Gene H.
>
Don't let us slow you down Gene!
Also be forewarned that I'm going to be hounding you to write an article for
curlBreaker.com -- especially after seeing how well you write :)
Regards,
-Chris
------------------
Chris Banford
ch...@bs...
bSoftware
Zermatt Switzerland
------------------
|
|
From: Dan B. <dbr...@wo...> - 2001-10-26 12:24:22
|
A somewhat confused person masquerading as Dan
Breslau wrote:
> FWIW, if the package load.curl is in the same
> directory as the file that imports it, you don't
> need a location hint at all (relative paths also
> work.)
What I suspect was intended was:
> FWIW, if the package load.curl is in the same
> directory as the file that imports it, you don't
> need a directory name in the location hint at all
> (relative paths also work.)
You do, of course, need to give the file name,
unless it's a built-in CURL.xxx package.
E.g.,
{import * from ORG.CURL-EMAIL.FOUNDATION,
location="Foundation.curl"}
-- Dan
|
|
From: Dan B. <dbr...@wo...> - 2001-10-26 12:13:32
|
Gene wrote: > I'm happy to report that I am now in a position to put together a > working foundation class library fairly quickly. [...] > I have worked with vendor supplied class > libraries prior to curl and one of the golden > rules that I have accepted is that you never > create an object in code that inherits directly > from a vendor library object. Instead all > objects inherit from your own objects in your > own libraries. Hence the idea of a foundation > class library that holds all your lowest level > objects that inherit directly from vendor > library objects. The result is that you can > make global changes in any of your objects by > changing the corresponding ancestor object in > your foundation class. > > So with the sample code above, instead of having > VBox objects throughout your code you would have > MyVBox objects. I've seen the advantages of > doing this on some fairly large projects and it > is hard to contemplate the alternative. > Ultimately you would probably have several other > objects in a UI package that inherit from MyVBox. > > You have probably read Dan Breslau's post where > he suggests that the golden rule cited above may > not be warranted and for sure suggests that > objects should be named according to their > function. My intent here is to get a feel how > the rest of the team thinks on these issues and > not to suggest that mine is the only way to go. Actually, most of that was between you and me (or that was my intent, anyway :-) I should start by saying emphatically that I don't want this to devolve into a style debate; *any* progress is better than no progress (which is all I offer right now.) Besides which, my own GUI skills are in the public view for you all to see :-) That said, I do think there could be reasons why this approach isn't necessary in Curl. Curl offers many ways to change an object's behavior other than inheritance; options and event handlers, to name two. You can do a lot without having to create subclasses at all. [...] > Finally a few smaller questions to think about. > The location specifier in the package > declaration above is specific to my computer so > we need to find a way to deal with that. > And how about author and version in the package > declaration. Are we going to use our own names > or a team name and what version to use for now? > And what about the file name Foundation.curl? > Do we want to think about standards for file > names and indentifier names? Also points of > style such as spaces around assignment > operators, etc. FWIW, if the package load.curl is in the same directory as the file that imports it, you don't need a location hint at all (relative paths also work.) We have used a convention here that test files can be placed in the same directory as the things that they test; the name is prefixed with "t-". So your test file could be "t-Foundation.curl", for instance. Thanks! -- Dan |
|
From: <gh...@nc...> - 2001-10-26 00:21:25
|
I'm happy to report that I am now in a position to put together a
working foundation class library fairly quickly. I would be
embarassed to say how long it took me to get this far but suffice it
to say that it has been a very good learning experience. There was
a bit of a learning curve to working with code in packages.
In this post I want to explain what I propose to do and ask for
comments to see if there is a consensus on it and related issues.
Ok, let's start with some sample foundation class library code.
Here is the current Foundation.curl.
------------------------------------------------------------------
||foundation class for curl-email project
{curl 1.6 package}
{package ORG.CURL-EMAIL.FOUNDATION,
author="",
version="0.1"}
{import * from CURL.GUI.BASE}
{import * from CURL.GUI.CONTROL-BASE}
{import * from CURL.GUI.CONTROLS}
{import * from CURL.GUI.EXTRAS}
{import * from CURL.GUI.SINGLETON}
{import * from CURL.GUI.STANDARD}
{import * from CURL.GUI.TEXT-EDIT}
{import * from CURL.GUI.TEXT-FORMATS}
{define-class public MyVBox {inherits VBox}
{constructor public {default ...}
{construct-super ...}
}
}
{define-proc public {my-vbox ...}:MyVBox
{return {MyVBox ...}}
}
{define-class public MyHBox {inherits HBox}
{constructor public {default ...}
{construct-super ...}
}
}
{define-proc public {my-hbox ...}:MyHBox
{return {MyHBox ...}}
}
{define-class public MyCommandButton {inherits
CommandButton}
{constructor public {default ...}
{construct-super ...}
}
}
{define-proc public {my-commandbutton
...}:MyCommandButton
{return {MyCommandButton ...}}
}
{define-class public MyTextField {inherits
TextField}
{constructor public {default ...}
{construct-super ...}
}
}
{define-proc public {my-textfield
...}:MyTextField
{return {MyTextField ...}}
}
------------------------------------
This is largely based on examples from the curl
basic docs for using rest arguments and the curl
gui docs for building custom controls.
Here is code that exercises the package above.
-------------------------------------------
{curl 1.6 applet}
{import * from ORG.CURL-EMAIL.FOUNDATION,
location="file:///c:/cvs/curlmail/curl-
email/Foundation.curl"}
{value
{MyVBox "test", background="pink", font-size=14}
}
{value
{my-vbox "test", background="yellow", font-
size=14}
}
{value
h:MyHBox = {my-hbox
background="blue"}b:MyCommandButton = {my-
commandbutton}
{h.add b}
{h.add {my-commandbutton}}
{h.add {my-textfield width=3in}}
}
-----------------------------------------
(some of the code lines probably got wrapped in
odd places but hopefully the intent is clear)
I suppose it is obvious that these rasise a
swarm of questions/issues.
I have worked with vendor supplied class
libraries prior to curl and one of the golden
rules that I have accepted is that you never
create an object in code that inherits directly
from a vendor library object. Instead all
objects inherit from your own objects in your
own libraries. Hence the idea of a foundation
class library that holds all your lowest level
objects that inherit directly from vendor
library objects. The result is that you can
make global changes in any of your objects by
changing the corresponding ancestor object in
your foundation class.
So with the sample code above, instead of having
VBox objects throughout your code you would have
MyVBox objects. I've seen the advantages of
doing this on some fairly large projects and it
is hard to contemplate the alternative.
Ultimately you would probably have several other
objects in a UI package that inherit from MyVBox.
You have probably read Dan Breslau's post where
he suggests that the golden rule cited above may
not be warranted and for sure suggests that
objects should be named according to their
function. My intent here is to get a feel how
the rest of the team thinks on these issues and
not to suggest that mine is the only way to go.
I am new to programming in curl and suspect most
of the team are relatively new to it too. My
experience with this type of situation is that
about the time we get the project finished is
when we'll know how we wish we had done it from
the beginning. Having a foundation class object
underneath all our objects will give us the
chance to go in and do some of the things we
wished we had done in the beginning with the
least amount of effort.
The base class objects are the most generic
objects of a given type that we will have. In
the spirit of giving them descriptive names we
could use GenericVBox instead of MyVBox or maybe
GenVBox. I am personally not fussy about the
exact name buy do prefer something rather short
and consistent. Note in the package code above
I have written a function for each class that
returns an object of the given class. This
would add a layer of indirection that may prove
valuable and I like it because the curl naming
conventions mean that function names are all
lower case. So whether to create all objects
through a function, directly from the class
name, or a mix of the two is a related question.
Finally a few smaller questions to think about.
The location specifier in the package
declaration above is specific to my computer so
we need to find a way to deal with that.
And how about author and version in the package
declaration. Are we going to use our own names
or a team name and what version to use for now?
And what about the file name Foundation.curl?
Do we want to think about standards for file
names and indentifier names? Also points of
style such as spaces around assignment
operators, etc.
I'm ready to move quickly on building a
foundation class which for starters would hold
all the visual GUI classes that I can come up
with. Foundation classes can also be valuable
for non-visual objects but it depends a lot on
what you're doing with them.
Your comments are requested and appreciated.
Gene H.
|
|
From: David G. <da...@cu...> - 2001-10-24 19:35:07
|
Actually this is more of a circular reference problem than a forward
reference problem (regardless of what the error message says).
Try this code:
{let public constant MyClassCallback:Type =
{proc-type {class:MyClass}:void}}
{define-class public MyClass
field public cb:MyClassCallback
{constructor public {default}
set self.cb = {proc {c:MyClass}:void}
}
}
It gives you the same error. Notice, if you remove the cb field from
MyClass the forward reference works fine. Also, you can keep the cb field
if you declare MyClassCallback -after- you declare MyClass.
I don't know why this works in some code and not in other code. I also
don't know why moving the callback after MyClass fixed the problem.
For the email client, I would suggest moving the callback declarations to
the end of the file an continue from there.
If I find any info about what's going on I'll post it.
--
Dave
"Mueffke"
<mueffke@gmx. To: <ch...@bs...>, "David Goldberg" <da...@cu...>,
net> <cur...@li...>
cc:
10/21/2001 Subject: curl-email: illegal forward reference in AsyncClientConnection.curl
05:47 PM
Please
respond to
"Mueffke"
Hi,
I tried to write a test for the SMTP package. I get the following error:
curl-email/curl-email/AsyncClientConnection.curl:26
Illegal forward reference in definition of AsyncClientConnectCallback
curl-email/curl-email/AsyncClientConnection.curl:34
Illegal forward reference in definition of AsyncClientConnectCallback
I don't understand that because it works in the email-client. I tried the
following and the same errors occured.
{curl 1.6 applet}
{import * from CURL.IO.SOCKET}
{include "AsyncClientConnection.curl"}
Some Text!
Do you have a clou what's wrong?
Friedger
PS: Have you seen cur...@li...
|
|
From: <gh...@nc...> - 2001-10-23 02:11:55
|
Hi guys, I'm on the email list now and just got cvs to create a checkout module with the current source. I caught the note about sending by smtp not working. Was glad to see this since I was feeling stupid when I tried to send an email that way and got no error but no message sent either. I will start on foundation class library for gui objects. For starters they will be copies of the curl classes untils we know enough about what changes we want to make. Naming convention will be CM-VBox for VBox, etc. unless I get requests otherwise. cheers, Gene H. |
