Hi Sandro, That took a while to read. :-) But thanks for the feedback. My comments below.
> I agree with Greg that RIA is a term a little outdated now so probably > even the R(Rich) part of it is not-so-much a strong point of interest > of Pivot (as could/will be for example in JavaFX, or Flash/Flex). Agreed - and the "rich" part of the acronym was never our primary focus anyway. It's there, but the emphasis was always more on "internet" and "application". > And even with the general idea that anything now should work inside > the Browser (Apple is trying to push this with HTML 5) and that Ajax, > Comet,the new Canvas, etc are best solutions for all problems ... but > (I could be wrong but) I don't think this. Agreed. The browser is one way to build and deploy internet-connected cross-platform applications, but it is certainly not the only way, and not always the best way. > - Internet-connected/enabled Applications, and this is already true > (we can improve, but I think we have a good degree today) > -- and on this, I'm working to simplify interaction with some web > frameworks, but this is another story ... From a strictly client/server perspective, we're in pretty good shape already - web queries are server-agnostic, and can be used to talk to any HTTP-based web service. However, what is potentially more interesting here are the CRUD frameworks - for example, it would be really cool to create a Grails plugin that would produce site scaffolding in BXML rather than HTML. A relatively thin Pivot loader app could retrieve these files from the server and present them to the user. > - Install via Internet (the Installable part of the probably new > acronym) ... and here I agree with others that probably here we have > to improve this part, that's why I push so much for example with > re-enabling Web Start support in our Web Site and in our Demos JNLP works, but IMO it is far from ideal. Windows users generally expect an .exe file and an installer, and Mac users expect an app bundle. I think we should include the ability to produce these deliverables in the platform (in the tools project, for example). There are some existing open-source projects that can do this. Launch4J can build Windows executables, and JarBundler can generate OS X app bundles: http://launch4j.sourceforge.net/ http://informagen.com/JarBundler/ It would be great if we could roll these into Pivot itself. A library that will automatically check for updates to an application would also be useful. > -- so on this I'd suggest if it's possible to insert something to > put in evidence the Upgrade part (if it makes sense). I think that's implicit in the "installable" part. > -- a little idea on this (maybe for a future Demo), something I call > "Enterprise Desktop", where like with Apache Maven, the user download > (manually or in other ways) the base installation, and then any other > content is downloaded Doesn't Eclipse RCP offer something like this? If we can get Pivot running on SWT, developers could conceivably just use this. Also might be able to take advantage of Project Jigsaw when it becomes available (hopefully in Java 8). > - Interactivity, no latency at any click (like page refresh now much > improved with Ajax or some trick like Javascript compressing and > precompiling) but only when the client ask for data. That can be controlled by the application. We don't need to do anything special to support that. > - Fast Interaction, like the previous point, but with the focus here > on how the framework let users to interact fast with application > features, for example with the keyboard (accelerators, consistency of > standards, etc) ... and here we have to improve in my opinion, if > possible starting for the 2.1 This is also an application design issue. The framework already provides the hooks for doing this. > - Load-balance between the client and the server, using the same > language, and sometimes reusing (parts of) the same code Also an app concern. > - Cross-platform ... but we are no more in J2ME/CLDC/etc days, so I > hope for the 3.0 we will be ready for modern Mobile platforms (mainly > Android 2.x, and maybe others but Open :-) ...) Agreed. I think the main platforms we should target are AWT/Swing, SWT, and Android. That will allow us to run on all desktops and many tablets. If we can get on Blackberry or Palm somehow, that would be great too. I'm not hopeful that we'll ever be able to run on Apple devices - Apple's policies with respect to Java are simply too closed. > - the multi-JVM language support, this is an important field for us > for next years but mainly for gain Developer's attention I think we've been doing a pretty good job with this already. > I agree with calatus that we have to improve giving some more shell > script or class to simplify execution of demos outside the browser. > Even in Eclipse, I think that adding a dedicated folder (maybe under > examples, so outside any release) with eclipse launch files could help Shell scripts are too clunky. I'd prefer to wrap them in native launchers using Launch4J or JarBundler. Also, while I think that this is a great idea for the demo apps, I think the tutorials should remain as applets, since their purpose is primarily to act as inline demos within the docs. > What I really think it's missing (due to lack of time, funds, etc from > any of us) is something that really uses the full power of modern > Desktops, for example like accessing local storage I don't think we need to focus on this. The JDK docs already cover this pretty well. I think we should focus on documenting APIs and features that we provide. G
