ravenous-redesign Mailing List for Ravenous
Status: Beta
Brought to you by:
kasperjj
You can subscribe to this list here.
2008 |
Jan
|
Feb
|
Mar
(10) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
---|
From: Kasper J. J. <kj...@so...> - 2008-03-22 20:50:51
|
Hi, This is the second preview of Ravenous v2. http://ravenous.solidosystems.com/files/ravenous-v2.0-b2.d41.tgz It is still very very very early. The primary things that have been changed, is the architecture for loading components. Its should now be very easy to add a python/ruby/groovy/scala/javascript engine to develop components in any of those languages as well as several others. Furthermore, a primitive version of the upcomming template system has been added. See the sample site for further details about this. Finally, I have begun implementation of the datasource system. Currently, it consists of the basic data types which will take over for the old FlexibleList and FlexibleHash classes, as well as a simple DataSource interface. Any comments on this would be very welcome. I am starting to add items to the task paper todo list which is included in the pack, currently small tasks that need completing in the source code. Let me know if any of you feel like attacking any of those. /Kasper |
From: Kasper J. J. <kj...@so...> - 2008-03-13 20:11:11
|
Hi, After a lot of late nights, I have finally completed a very early preview of the next version of Ravenous that will actually run. A lot of it is very simple and incomplete, non the less, you can actually run it and view a little sample site in action. The distribution is stored at the following location: http://ravenous.solidosystems.com/files/ravenous-v2.0-b2.d18.tgz In it you will find a file called administrators_guide.txt that gives a brief intro to actually getting it running. You will also find hackers_guide.txt which gives a very crude intro to how some of the internals work. If you wish to play around with the sample site, be aware that you currently need to restart ravenous for it to recompile and reload templates and components. At this point, I'm going to continue working on the internals to get the basics more complete. The layout and component system is still very simple. I'm going to leave it as it is for now until we finalize how its going to work. The datasource framework is still completely untouched... if anybody wants to write up a proposal for how that could be done, that would be great. Let me know what you think about the direction its moving in :-) /Kasper |
From: Jim C. <Jim...@sa...> - 2008-03-06 12:22:56
|
> > Why not component, @component, and $component? > > I'm not sure I get what you mean by that? Just using the sample syntax you gave for local, shared, and global variables, but using 'component' instead. |
From: Kasper J. J. <kj...@so...> - 2008-03-06 04:59:09
|
> Shared (even global) components would be very important for several > reasons, including: > > * Performance > * Memory usage (or "footprint") > * Consistency > * Pooling Definitely, however there are issues with clustered server setups.. it might make sense to allow both shared components on each web server, but also globally shared components on a separate shared server that all web servers have access to through some sort of RPC. > Why not component, @component, and $component? I'm not sure I get what you mean by that? > I _think_ what I read would allow me to have multiple layouts on a > single page, but that might be clarified. Would be nice to be able > to have a header layout, body layout, and footer layout (all within > the <body></body> section). You could change one of them and it > would only affect that section of the page. If I read correctly, > you could do that by putting each section into a separate > component... of course, if layouts were just specialized components, > you would already have your components... Yes, multiple layouts on a single page would be possible.... but try thinking of layouts as holders of components. Components will also have templates, so for stuff like a header and a footer, a simple component with a template could easily be used. But this is definitely one of the areas that have several ways of being designed. Each with their own benefits and drawbacks. I still think the separate Layout and component model would be the best since it would allow each to be simpler and each to have a more clearly defined role.... Layouts hold components, pass events onto them and collect their output. Components contain state, react to events and render an html representation of themselves. However, that doesn't mean I don't see the beauty in a pure component model. Everything is a component and a component can hold other sub components. > How modular will the new Ravenous be? For example, will I be able > to plug-in a jython component, and add python code to my site? Yes, that would definitely be part of the plan. I'm not sure what the best way to do it will be, but the design I'm experimenting with in my prototype has all the resources needed for a component in a separate folder. When the component is needed, a component loader is asked to create one based on the files in the given folder, so it would definitely be possible to have the component loader create very complex components behind the scenes. I know kasper langer is very interested in using groovy for writing parts of his sites. One of the things I'm really excited about is integrating this structure with the scripting engine system in java 6, that would open up a ton of scripting languages allowing people to utilized the structure of ravenous to write web sites in their favorite language. > I dream of a fully interactive page, where you wouldn't know the > difference between it being a desktop app vs a web page... your > ideas about transparent ajax code would certainly help with that. :-) You could actually go even further out than this and create a component you could inherit to do swing style gui programming. The component would automatically create html for gui components, set up event listeners and so forth to dispatch inner classes when events arrive. > Just more thoughts. The brainstorming part of a new design is > always the most exciting, isn't it? :-) he he.. definitely. That and starting to see things work. :-) /Kasper |
From: Jim C. <Jim...@sa...> - 2008-03-04 03:49:07
|
> -----Original Message----- > From: rav...@li... [mailto:ravenous- > red...@li...] On Behalf Of Kasper Jeppe > Jeppesen > Sent: Monday, March 03, 2008 18:06 > To: rav...@li... > Subject: [Ravenous-redesign] New Ravenous Ideas > > Hi, > > I very much agree with the comments that a new database/datasource > interface should be a vital part of the new design. Some of what > Daniel suggested about having a job pooling functionality actually > leads very well into my ideas for the next version of Ravenous, so I > thought I might as well throw it out there. So here we go... with far > less figures and samples than I originally intended ;-) I like it so far. :-) Shared (even global) components would be very important for several reasons, including: * Performance * Memory usage (or "footprint") * Consistency * Pooling * ... Why not component, @component, and $component? I _think_ what I read would allow me to have multiple layouts on a single page, but that might be clarified. Would be nice to be able to have a header layout, body layout, and footer layout (all within the <body></body> section). You could change one of them and it would only affect that section of the page. If I read correctly, you could do that by putting each section into a separate component... of course, if layouts were just specialized components, you would already have your components... How modular will the new Ravenous be? For example, will I be able to plug-in a jython component, and add python code to my site? I dream of a fully interactive page, where you wouldn't know the difference between it being a desktop app vs a web page... your ideas about transparent ajax code would certainly help with that. :-) Just more thoughts. The brainstorming part of a new design is always the most exciting, isn't it? :-) |
From: Kasper J. J. <kj...@so...> - 2008-03-03 23:27:44
|
I forgot to add the most important idea that really makes this new framework shine :-D It would be possible to write a little javascript stub that used ajax to send events back to ravenous when the user interacted with the site. Ravenous would then process the events as usual, but only return the output of the components that had changed. The javascript stub would then replace the contents of these changed components when it received the response. From a developer standpoint, we could simply create a component you inherit that can generate the right ajax links, forms and so forth for you. After that, you wouldn't have to think about it. The rest of your components, even the ones that will purely send their response back as a result of ajax calls, you just write as you would any other component.... the ajax thing happens completely transparently. :-) /K |
From: Kasper J. J. <kj...@so...> - 2008-03-03 23:06:19
|
Hi, I very much agree with the comments that a new database/datasource interface should be a vital part of the new design. Some of what Daniel suggested about having a job pooling functionality actually leads very well into my ideas for the next version of Ravenous, so I thought I might as well throw it out there. So here we go... with far less figures and samples than I originally intended ;-) The current architecture works in much the same way most other web frameworks work. A request comes in, through some method of routing, you figure out which controller/page/servlet its intended for, run the code at that location, optionally pump the results through a template system and deliver the results back to the browser. What I have been thinking about is closer to the way frameworks such as seaside ( http://www.seaside.st/ ) works. A website is composed of a set of components. Every user will have his own set of component instances that stay alive between each request. When a request comes in, it is treated as an event. All components that have registered to listen for this event will receive it. Once all events have been processed by components, the system will ask each component to deliver a string representation of it self. This will be the output from the request. Lets look at a less abstract sample. Imagine a very simple website that consists of a little form in the middle with a button and a text field containing the number 0. When you click the button, the in the text field is incremented by one. This form could be generated by a component. The component has an internal integer value which represents the number in the text field. The first time the page is shown, the component is asked to deliver its html representation. It will generate the form and set the text field to the value of its internal integer. When the button is pressed, an event is sent to the component. When the component processes the event, it increments the integer. After all events have been processed, the system asks the component for its html representation again and it will once again deliver the little form, but this time, the number will have been incremented by one. Very simple... now, lets look at some details for how this could work. In the components constructor, it will ask to receive events for the path /mycomp/increment. When it generates the form, it sets the forms target path to /mycomp/increment. Thus when the button is pressed and the form is posted, ravenous will inspect the path and send the request as an event to the component because it requested all events for that path. After the event has been processed, Ravenous asks for the components output and returns it to the browser. Lets quickly look at a possible piece of code for this component. public class MyIncrementer extends Component{ private int counter; public MyIncrementer(){ counter=0; acceptEvents("/mycomp/increment/"); } public void processEvent(Event evn){ counter++; } public String render(){ StringBuilder buf=new StringBuilder(); buf.append("<form action=\"/mycomp/increment/\">"); buf.append("<input type=\"textfield\" value=\""+counter+"\">"); buf.append("<input type=\"submit\" value=\"increment\">"); buf.append("</form>"); return buf.toString(); } } Having just one component is clearly very boring... its almost like writing servlets ;-). So lets introduce another element - a layout. A layout is an html template that holds components. If we imagine a slightly more complex site, with two components, a menu component and the MyIncrementer component, the Layout could look like this: <html> <head> <title>My Site</title> </head> <body> <?comp id = menu class = MyMenu ?> <br /> <?comp id = inc class = MyIncrementer ?> </body> </html> When Ravenous gets a new user for the site, it loads the layout and instantiates the embedded components. When it gets a request it can now ask the Layout to process the event and return the correct html output. The layout will then send the event to all relevant components and ask each of them for their output which it will embed in the right places before returning the full output. I hope you guys are following me so far, because I'm going to throw out a couple of ideas that build upon this model, but haven't been thought out completely yet, so they might take a bit of imagination ;-) * A site can have more than one layout. Imagine a layout for the login screen, a layout for the general user interface and a layout for the admin interface. When the login completes, it asks the system to change the current layout to either the user interface or admin interface depending on the credentials given. * Each component, layout and user instance will have its own hash of values. These can be referenced using foo, @foo and $foo as commenly used in scripting languages. Think of these as local, instance and global variables. I imagine that you would simply set or get them by calling set or get in your component. By using the instance values for the layout, or the global values, components can communicate with each other and leave information for templates. Imagine for example that the menu component in the previous sample code could leave the title of the currently selected menu item for everybody else by calling set("$menu_item","foo"); This value could be accessed by other components calling get("$menu_item"); but also in templates such as the layout simply by embedding $menu_item or maybe {{$menu_item}} as in django templates. * Components could be allowed to instantiate Layout's and use them in their processing. As an example, you might have a component that holds two different layouts internally and switches between them when it receives specific events. Each layout might represent the content for a different menu item. All the menu component has to do to switch between the different contents is then to create an event for the layout switching component. Or think of it the other way around, all the layout component has to do is listen for the menu switching events. * Layouts would not always have to be controlled from a file based template. Its easy to imagine a layout that simple adds components in separate divs below each other. This could be used for a frontpage on a site like slashdot.org with each news item being a separate component. * Notice how the above component was using a StringBuilder to create its output. It would be easy to create a BufferedComponent class to extend instead, that had print and flush methods. Then you could generate your output while processing an event, the component would then buffer it internally and unless new events had been received, the component would just return the cached result. * This buffered component could be extended even further to have a component that also implements the event processing method and uses reflection to figure out which method to call. This would result in a coding style very similar to the current ravenous's controller system. * A combination of the two could be expanded with a template system, so when an event is received, the component finds the right method to call, then the right template to generate output from which it can then store in its buffer. * Components could use delegates to process events as is used in Objective-C * Components could be allowed to send of new events to other components, not just when requests are received. * Components could be packed in a separate folder (or jar file if one wishes) by itself. Installing a third party component would then just be a case of dropping it in a components folder and start using it in your Layouts. In the same way as I gave an id and class value to the components in the above sample, other values could be given to the components to configure them. As an example, one could easily imagine a generic menu component or user authorization component, paged table view component and so forth. * It would be very easy to create a component debugger where you could fully create and debug you component without needing the rest of the site to be working. It would be equally easy to setup unit tests for the individual components. This sort of development would finally allow you to split up the development of different parts of a complex web site without the individual developers being dependant on anything but specifications from each other. * If we create a very generic datasource framework, components could easily use foreign data sources simply by telling them what the name of the data source is and what columns it should use. This would work both for user authentication and visual things such as table views. * It would also be possible to imagine components which are shared between users, not just to save memory, but also to do cached shared data. * Kasper Langer at solido systems suggested that layouts could just be specialized components. While I do see that this would be a nice simplification of the overall model, I do like the separation of responsibilities between components and layouts. There are tons of other little ideas buzzing around in my brain about this framework so far, but let me know what you guys think. I know this is a big departure from the previous version of Ravenous, but I do think its an exciting one that would allow the new version of ravenous to do things that would be very hard in other frameworks... most of all, it would make it possible to create a viable market place for components, both commercial and open source. Let me know what you all think and if you have any questions.... oh, and as a little teaser, I do have a very simple prototype of this system working on my laptop right now ;-) /Kasper |
From: Jim C. <Jim...@sa...> - 2008-03-03 21:36:37
|
Simple is good to start. A second level would be to have "roles". This data could be stored in any database (LDAP, SQL, flat-file, ...), allowing only subsets of people to perform certain actions (or even see particular pages/URLs). From: Daniel Knippers [mailto:da...@kn...] Sent: Monday, March 03, 2008 16:28 To: Jim Cooper Subject: Re: [Ravenous-redesign] List of issues It would be nice to have a "common" security interface for authorisation and authentication. By default Ravenous should then ship with a working implementation for "simple" user authorisation and authentication. The reference authorisation method could be basic http header login or of even nicer a login page/form. The reference authorisation scheme could be at a level of partial url matching (e.g. allow/deny /test/* /page/*.rvp). A more advanced security implementation could then be LDAP integration. I think the security implementation should follow the same abstraction model as the database model (or the other way around for that matter). Another idea is to implement some job/pooling/queuing implementation which is available to the ravenous dynamic code (rvc, classes, etc) and plugins as well. This can then be used for robust mail functionality or graphics/graphs generation in the background on a periodic basis. I agree with Jim that the database "common" interface should be able to support whatever database you would like. But it might be wise to stick with JDBC (there are a lot of drivers out there) as a basis model for databases. I am looking forward to see your plans as well. Daniel On 3 Mar, 2008, at 20:55, Jim Cooper wrote: For database support, it would be good to be able to use whatever type of database one wished, while using a "common" interface. There are times when a flat-file "database" is all you need. For performance, you might want to use an embedded database (such as Apache Derby). The security system might be based on LDAP... or it might not. Should be configurable. You might need to connect to an enterprise-level database, that may or may not use SQL. I know that it would be an... interesting task to try to build in support for all these types (and others I haven't mentioned or don't know about), but it would be good to try to keep the database support as flexible as possible, possibly with multiple interfaces (maybe a 'dbType' variable?). That's just my first thought. I'm very interested in seeing/hearing about your planned changes. :) From: rav...@li...<mailto:rav...@li...> [mailto:rav...@li...] On Behalf Of Kasper Jeppe Jeppesen Sent: Monday, March 03, 2008 13:08 To: rav...@li...<mailto:rav...@li...> Subject: [Ravenous-redesign] List of issues Hi, I thought I would start this list of with a brief history of Ravenous followed by a list of the primary things I want to see different/fixed in the next generation :-) In the beginning of January 2005 I needed to start work on a new web interface for an email server product we were developing at Solido Systems. Up until that point, I had been developing in PHP, but honestly... I was fed up with PHP. Both the language and the insanely inconsistent libraries. I know much have changed since then, but at that point, PHP was in my opinion a horrible platform to do complex web development on. What I really wanted was something very similar, but with a better language and a more consistent library. That gave me the idea to start the first version of Ravenous. When I released it onto the rest of the world in may 2005, that was pretty much what it was. A PHP like system with Java as the language. Not long after, I started reading about some of the exciting things the ruby on rails project where doing and added the MVC model to Ravenous in a way very much inspired by rails. The project kept being developed along side the web interface I was developing in it. New features was thus added as I needed them. In some ways, this was a very healthy process, but it also led to a very incremental development process where a lot of features where squeezed into places where they really didn't belong, resulting in the pretty messy source base we have today. The call to do a rewrite is not just to fix a messy source base, there are also several things I would like to do different and several new ideas I would like to try out. Lets first have a quick look at the things I think needs changing. If you have other items, please reply with them to the list. * Each virtual host should reload its entire site everytime something changes so every class is loaded with the same classloader. * It should be possible to add plain classes along side controllers that use them instead of having to add them as an external lib or in the model folder. * Inheritance should be a more natural part of development. * I would like to see a lot of the features implemented using less code generation and less "magic" making it more comprehensible what is happening when you are working on bugs. * I would like to see a more advanced template system, with less code and more tags... I think the template engine used in Django is a good model to aim for. * Data retrieved and prepared in controllers shouldn't need to be explicitly transfered to templates like its currently being done with the ENV hash. * The db.conf file should be expanded as a general site configuration system * I would like to see a rich plugin architecture both for visual components, but also for backend objects and template enhancements. * I like some of the ideas behind the current data source framework, but would like it to be more easily maintained by hand and at the same time be more flexible to cover both database connections, local data files and external web services. * We NEED a full security manager. I think this is one of the biggest issues with the current version of Ravenous. There are a ton of other smaller things I would like to see changed, but they are mostly just different ways of implementing the same functionality. I do however have some new ideas for a very different way of implementing Ravenous. It will share some ideas with the current version, but will also represent a radical departure towards a different development model. I will be posting another email describing that idea, but for now, let me know what you would like to see different in the next version of Ravenous. /Kasper ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/_______________________________________________ Ravenous-redesign mailing list Rav...@li...<mailto:Rav...@li...> https://lists.sourceforge.net/lists/listinfo/ravenous-redesign |
From: Jim C. <Jim...@sa...> - 2008-03-03 19:55:33
|
For database support, it would be good to be able to use whatever type of database one wished, while using a "common" interface. There are times when a flat-file "database" is all you need. For performance, you might want to use an embedded database (such as Apache Derby). The security system might be based on LDAP... or it might not. Should be configurable. You might need to connect to an enterprise-level database, that may or may not use SQL. I know that it would be an... interesting task to try to build in support for all these types (and others I haven't mentioned or don't know about), but it would be good to try to keep the database support as flexible as possible, possibly with multiple interfaces (maybe a 'dbType' variable?). That's just my first thought. I'm very interested in seeing/hearing about your planned changes. :) From: rav...@li... [mailto:rav...@li...] On Behalf Of Kasper Jeppe Jeppesen Sent: Monday, March 03, 2008 13:08 To: rav...@li... Subject: [Ravenous-redesign] List of issues Hi, I thought I would start this list of with a brief history of Ravenous followed by a list of the primary things I want to see different/fixed in the next generation :-) In the beginning of January 2005 I needed to start work on a new web interface for an email server product we were developing at Solido Systems. Up until that point, I had been developing in PHP, but honestly... I was fed up with PHP. Both the language and the insanely inconsistent libraries. I know much have changed since then, but at that point, PHP was in my opinion a horrible platform to do complex web development on. What I really wanted was something very similar, but with a better language and a more consistent library. That gave me the idea to start the first version of Ravenous. When I released it onto the rest of the world in may 2005, that was pretty much what it was. A PHP like system with Java as the language. Not long after, I started reading about some of the exciting things the ruby on rails project where doing and added the MVC model to Ravenous in a way very much inspired by rails. The project kept being developed along side the web interface I was developing in it. New features was thus added as I needed them. In some ways, this was a very healthy process, but it also led to a very incremental development process where a lot of features where squeezed into places where they really didn't belong, resulting in the pretty messy source base we have today. The call to do a rewrite is not just to fix a messy source base, there are also several things I would like to do different and several new ideas I would like to try out. Lets first have a quick look at the things I think needs changing. If you have other items, please reply with them to the list. * Each virtual host should reload its entire site everytime something changes so every class is loaded with the same classloader. * It should be possible to add plain classes along side controllers that use them instead of having to add them as an external lib or in the model folder. * Inheritance should be a more natural part of development. * I would like to see a lot of the features implemented using less code generation and less "magic" making it more comprehensible what is happening when you are working on bugs. * I would like to see a more advanced template system, with less code and more tags... I think the template engine used in Django is a good model to aim for. * Data retrieved and prepared in controllers shouldn't need to be explicitly transfered to templates like its currently being done with the ENV hash. * The db.conf file should be expanded as a general site configuration system * I would like to see a rich plugin architecture both for visual components, but also for backend objects and template enhancements. * I like some of the ideas behind the current data source framework, but would like it to be more easily maintained by hand and at the same time be more flexible to cover both database connections, local data files and external web services. * We NEED a full security manager. I think this is one of the biggest issues with the current version of Ravenous. There are a ton of other smaller things I would like to see changed, but they are mostly just different ways of implementing the same functionality. I do however have some new ideas for a very different way of implementing Ravenous. It will share some ideas with the current version, but will also represent a radical departure towards a different development model. I will be posting another email describing that idea, but for now, let me know what you would like to see different in the next version of Ravenous. /Kasper |
From: Kasper J. J. <ka...@na...> - 2008-03-03 18:10:03
|
Hi, I thought I would start this list of with a brief history of Ravenous followed by a list of the primary things I want to see different/fixed in the next generation :-) In the beginning of January 2005 I needed to start work on a new web interface for an email server product we were developing at Solido Systems. Up until that point, I had been developing in PHP, but honestly... I was fed up with PHP. Both the language and the insanely inconsistent libraries. I know much have changed since then, but at that point, PHP was in my opinion a horrible platform to do complex web development on. What I really wanted was something very similar, but with a better language and a more consistent library. That gave me the idea to start the first version of Ravenous. When I released it onto the rest of the world in may 2005, that was pretty much what it was. A PHP like system with Java as the language. Not long after, I started reading about some of the exciting things the ruby on rails project where doing and added the MVC model to Ravenous in a way very much inspired by rails. The project kept being developed along side the web interface I was developing in it. New features was thus added as I needed them. In some ways, this was a very healthy process, but it also led to a very incremental development process where a lot of features where squeezed into places where they really didn't belong, resulting in the pretty messy source base we have today. The call to do a rewrite is not just to fix a messy source base, there are also several things I would like to do different and several new ideas I would like to try out. Lets first have a quick look at the things I think needs changing. If you have other items, please reply with them to the list. * Each virtual host should reload its entire site everytime something changes so every class is loaded with the same classloader. * It should be possible to add plain classes along side controllers that use them instead of having to add them as an external lib or in the model folder. * Inheritance should be a more natural part of development. * I would like to see a lot of the features implemented using less code generation and less "magic" making it more comprehensible what is happening when you are working on bugs. * I would like to see a more advanced template system, with less code and more tags... I think the template engine used in Django is a good model to aim for. * Data retrieved and prepared in controllers shouldn't need to be explicitly transfered to templates like its currently being done with the ENV hash. * The db.conf file should be expanded as a general site configuration system * I would like to see a rich plugin architecture both for visual components, but also for backend objects and template enhancements. * I like some of the ideas behind the current data source framework, but would like it to be more easily maintained by hand and at the same time be more flexible to cover both database connections, local data files and external web services. * We NEED a full security manager. I think this is one of the biggest issues with the current version of Ravenous. There are a ton of other smaller things I would like to see changed, but they are mostly just different ways of implementing the same functionality. I do however have some new ideas for a very different way of implementing Ravenous. It will share some ideas with the current version, but will also represent a radical departure towards a different development model. I will be posting another email describing that idea, but for now, let me know what you would like to see different in the next version of Ravenous. /Kasper |