This isn't in the Drupal tag so that it won't go to the Planet; but I want this information easily available.

I want to record this conversation; I'm also lazy so I'm not really rewriting it, but I did edit it down somewhat. In short, fago and I spoke about Views 2 and what I have planned and what he can do to help. I ended up with a pretty good summary of the things I want to do:

Hey I want to be able to do node family type stuff in Views 2. I'm thinking of having fields/filters/sorts which link back to the base table be able to have a dropdown which lists all variants of the base table that are currently in the query, and things like nodereferences, et al, could advertise these variants.

And Views 2 should also have selectable base tables, so you can base it off user or node or custom.

The sort of larger view in my head is: 1) clean up the API on the handlers. They should *all* include the $view as an argument. 2) Change how field/sort/filter etc are listed so that they use optgroups

Then you just stick your fields in the proper optgroup
Allow configurable base table, and allow field/sort/filter values to specify which instance of the table they connect to, if there are multiple instances in the view.

I want to redo the admin UI so it uses tabs for the sections rather than fieldsets.

[fago] Do you plan to clean up the argument handlers too?
Yes, though I don't have a clear sense of how to clean them up.
But I think each of the operations in an argument handler should be its own function.
[fago] It would be cool if it views could a default autogenerate argument handlers, if there is a filter.

I don't know that filters will contain enough info. It's a little tricky to generate the summaries. But if you can figure out a good algorithm for doing that, I'd be open to it
[fago] If the field and filter info would be combined, it should be doable.
[fago] However, that would go more in the directoin that one specifies how the database layout looks like and the what the meaning of the columns is, and views does the rest.

Not all filters have fields, necessarily. Though it is entirely possible that I've been stingy about fields. But I surmised that nobody would want 'sticky' as a field.
[fago] hm, that might useful too. e.g. for admins
[fago] But everyhting, that should be an argument, has to be a field. Otherwise there can't be a summary
Hm. Perhaps. The summary title doesn't always match the use of a field. And there's a lot of code in summary titles for exceptions. Like Anonymous for user 0 and Uncategorized for no term, etc.
[fago] hm, that's right, so this would require the possibility to override the field display to something different

Right. So now we're getting pretty complex...
[fago] however, I fear this appraoch might be too much, too difficult and too much work.. ;)
It's a nice thought, though, and it's worth keeping on the drawing board in case there is some inspiration.
Ok, another improvement Views 2 needs: OR filters. I was thinking what we need is filter groups.

I also have some js code to move items up and down in a list; I want to implement it in nodequeue and get it good and solid, and then use that in Views.

Between that, tabs and some AJAX to add new items without having to refresh the whole page, I think the UI can be a lot slicker.

Oh, and the other idea I've been toying with. I think Views needs separate output widgets. i.e, the 'block' output, the 'page' output, the 'embedded' output (of which there can be multiple, arbitrarily named).

And they each get their own Fields list.

Thus you can have the one view that does block/page, and lists different fields in the block than the page and doesn't need theming.

Then we somehow wrest summary views into that framework (if we can; they're weird and thus difficult).

Oh, and plugins need to be able to have a config block.

[fago] I would be also great, if it's easy to build forms with views - as a module developer
I agree. There are several people working on things that do that. I haven't spent much time looking at them, but Views 2 should at least make their lives easier.
So that 'form' could be a plugin.

[fago] What's about db support? Have you thought about dropping support for mysql < 4.1, so views could make use of subqueries?
Not in Drupal 5. Drupal 6 will drop < 4.1, so Views 2 can if we target it for Drupal 6. Which is actually probably realistic. I don't know that I have the ability to get it done as a Drupal 5 module. But I'm not sure I should force that

Oh, there is one last thing: I want to include some caching ability. Probably configurable.
[fago] do you mean more sophisticated query caching?
Output caching. Not all views need their information in realtime. I think what it should probably do is allow hooks for caching mechanism, and let modules handle it. And basically let a module 'claim' a view and handle the caching. And if done right, this could allow modules to be very smart about it, and easily expandable. And sites with specific needs could set up caching for their own needs using the API.

If you want to help, the first thing we probably need to do is identify the APIs of new features and APIs that need to change so we can standardize them.

[fago] What's the first part you'll plan to get done? I guess the whole views API + the query building?
Yea, the API part has to get done first, including any database changes that it requires. Which means having configurable output types is probably the very first thing.

Actually, database stuff comes before API, really. Also, bleh. That's part of what's stalling me. So tedious. =)

In addition to what we actually chatted about, I also have on my list that it really needs better handling for taxonomy -- and the ideal way to do this would be some better handling for hierarchy in general. But I haven't got anything concrete about how to do that.