Curl has enjoyed a lot of success outside of Japan over the course of the past 18 months, but we need your help to become a better RIA platform.
Next week the product, marketing and sales teams at Curl, Inc. are meeting to discuss the future of Curl. What our road plan should be, where we need to improve, and to re-evaluate our focus. Its something we do four times a year but this time it’s more critical than ever before. With the economy in the US and abroad suffering Curl is going to have to really distinguish itself in order to capture the imaginations and mind-share of the World's RIA community.
We have explained our performance and security benefits and it’s now clear to most people that Curl is a heck of a lot faster and more capable of handling large data sets than anything else, but this isn't good enough. We need to do a lot more to make Curl the best RIA product available.
I recently posted a blog entry to InsideRIA.com asking people "Why didn't you choose Curl?" The question is sincere and the responses are helping us understand the market better.
Now I'm asking you, our community members, the people most familiar with the Curl platform, to let us know "What can we do better?"
Tell us what frustrates you. What do you want Curl to do to make the platform better. You can also tell us what you like about the platform but the emphasis should be on improvement not shoulder slapping. Be honest. Be sincere. Know that we are listening to you intently and will take all suggestions seriously.
This is your chance to make a difference in a product you know and use. We are not some huge company that ignores the desires of its development community. We are small and agile and will do whatever we can to make Curl the most attractive RIA platform on the market.
You can make a difference. Tell us what we need to do to make Curl the best RIA platform available.
Curl Blog
Previous Next
URPradhan
Good comments added at insideria site. there is a poll for the RIA technology @ http://oreillynet.com/insideria/polls/193.csp
URPradhan
in response to: URPradhan
http://visudemos.ilog.com/blogsamples/olympics/olympics.html
http://examples.adobe.com/flex2/consulting/styleexplorer/Flex2StyleExplorer.html
rhh
in response to: URPradhan
Regarding the Flex style explorer, have you looked at the Curl style explorer that you can access from here:
http://developers.curl.com/docs/DOC-1156
rshiplett
Frankly I would either fix some of the worst bugs in the IDE or get it out into opensource where some of us will fix them. And add a refactoring browser in the process. The current object inspection is awkward and falls far short of other IDE's. And not bet the farm on Eclipse.
rshiplett
Document at least as much of IPC as was available in the CSK and at least as much as Chris is using a Zuzu. Inter-Process Communication is our subapplet technology and even if it is not often needed, as Bert has said elsewhere, it is sometimes essential and needs to be in the documentation.
rshiplett
Take a page from ICON/UNICON and add generators as an explicit language feature.
ICON used the idiom of 'every'
rshiplett
Visual object inspection, options improvement: any graphic which has a name option set for it or in a parent should default to displaying that name when inspected (with he name in parens if it found name = some non-empty string in a parent).
'name' is one of the most useful options when coming back to maintain a Curl GUI of any complexity.
rshiplett
Add "active scripting" as a feature. Long a feature of Smalltalk object inspectors, in Curl it seems to require a breakpoint and then the awkward "paste into expression evaluator" with no easy inspection of that resulting value.
No, Smalltalk is not dead; (Minneapolis has much more corporate Smalltalk than Curl - and new Smalltalk projects at that). Requests for Smalltalk developers in USA still far out-strips requests for Curl developers. And on the client-side, Smalltalk now has Seaside + Magritte + Pier. Squeak Smalltalk has a very active user community. Even Rebol (also an expresion-based language) appears to have a larger active developer community at ALTME than has Curl here at the moment. Following the fate of UNICON, the follow-on to ICON, is rather sobering: the IDE was the problem, imho, and still is. ICON is a great langauge with almost no users outside of academe.
rshiplett
Distribute Curl with at least one explicit, working, useful, domain specific language or DSL or dialect.
rshiplett
Add support for accessing parameters of <OBJECT> when embedding Curl in HTML
rshiplett
Allow a "master" PRO Curl development environment to run "headless" as an NT Service. This appears to be required for automating PCurl scripting in an industrial environment using Eclipse + ANT with WIN32 servers.
rshiplett
Add support for constraint handling rules (CHR) for both visual and non-visual expression evaluation. Programming with constraints need not be left to special libraries or CLP languages.
cbarber
in response to: rshiplett
What explicitly are you referring to regarding looking beyond HTTP/HTTPS? Is there some other protocol you are thinking of? In the past we have considered supporting FTP, but it seems to be used less and less.
rshiplett
in response to: cbarber
FTP? That sounds like "looking back", not "looking beyond".
When TCP turned 15, we were still waiting for the "year of unix" to arrive. The net arrived instead.
Now we have a whole movement making a "virtue" of HTTP being stateless. But if we also had Curl on the server-side, we could be looking at an OTP and a DOTP which would try to learn from the problems which beset both CORBA and EJB's. Or am I to believe that XMLHttpRequest is as far as we get on the web in my lifetime?
If Curl is viewed just as an alternative to HTML+JS+CSS, then perhaps we are not going to envisage a COTP.
Curl managed to get beyond the "cookie" with CSPD, but , OCC aside, seems to have stopped there.
Curl-beyond-the-browser, RIA DCurl, would not have to be a Curl bound by HTTP anymore than we need be limited by XML now.
rshiplett
Two features found to be useful elsewhere:
Smalltalk reflection has an allInstances method to which a class responds with a collection. In Curl that would be {aClassType.all-instances}
REBOL has a name option for visuals which can be used to locate that object. In Curl that might be {aClassInstance.named aName}
There are no doubt ways of doing both in Curl now, but they are not explicit ( our visual name option is just a useful tag at the moment.)
rshiplett
|| Permit restricted method over-loading.
|| For example:
{define-class flexible FlexiClass
{method {some-method i-parm:int}:int
}
}
{define-class Sub-Flexi {inherits flexible FlexiClass}
{method overloads {some-method f-parm:float}:float
} || if parm is int, passes up to super is we did not override
}
|| perhaps only in a less than stringent package and not yet across packages in 9.0
|| relax override restrictions on parameter identifiers and identifier counts (signatures)
rshiplett
Two other expression-based languages, Rebol and UNICON (ICON) have stronger string processing facilities than CURL. As both of those languages continue to evolve, we might take a page from their book, so to speak. It is interesting to note the renewed interest in the facilities of SNOBOL in the UNICON community.
cragthehack
Being new to Curl I can't comment on the tech issues, yet. But, reading the comments at InsideRIA- most of them referred to the look of Curl. And they're right. It does look like some 1989 dBase app. Even enterprise's want good looking apps. Also, (and I'll probably get flamed for this) get a Mac specific version of the IDE. I mean com'on! This is a no-brainer. Every web/net geek in America either has a mac or wants one.
rshiplett
When reviewing this recent code variant for a remote.curl file
|| do not run as web CURL launch or <OBJECT> - this is a SUBAPPLET
|| called from regular browser applet
{curl 6.0, 7.0 applet}
{import * from CURL.REMOTE}
It seems apparent that we could well use
{curl 6.0, 7.0 subapplet}
or
{curl 6.0, 7.0 remote-applet}
as headers for what we might well suffix with extension
remote-something.Rcurl
without imposing anything
At the moment a remote applet CURL tends to open as a blank browser page when executed directly by error as a Curl file.
I think of
{curl 6.0, 7.0 subapplet}
{subapplet
error-msg = "remote applet; call thru remote interface",
error-widget = popup-message,
error-action = exit
}
rshiplett
I would like to see a graphical indication option in the project view to give me an immediate heads-up when I open a project for code review or other eval that the project is made of packages with inconsistent compiler directives (inconsistent to the extent that one is weaker or one sets, say, package defaulting to true and soem one other does not)
In PITL it is so important to be able to see what is the status of a project which is destined for commercial production use. And this seems an easy one to provide as a project properties option.
If the IDE were in opensource, I would certainly put it in myself.
Ditto if not all packages have the same PCurl settings ( we have something like this for which resources are destined for deploy)
cbarber
in response to: rshiplett
Regarding the all-instances idea. I have sometimes wanted such a thing when debugging. I think that might be possible but it would not be fast since we would have to search the heap for the instances. This could also include some instances that are waiting to be collected. We might want to consider whether this ability should be restricted to privileged processes since there may be security implications.
Can you provide some possible use-cases for this feature?
Thinking about why my employer didn't choose Curl leads me to the following suggesting: Curl can't change the runtime distribution or descrease the risks for enterprises - that is a different topic. Technically, it would be great to have a better integration with the office world. My employer was looking for an easy API to connect to Outlook, manipulate Excel or Word documents.
What I am missing is a business model for small companies/small commercial projects, but that's more a personal thing.
Friedger