Posted by bjaspan on January 17, 2008 at 4:56am
We have Monday, Tuesday, and Wednesday afternoons and evenings in Palantir's conference room. We can schedule things in the morning, too, thought I'm thinking we should reserve that time for people to do personal work and/or hack code based on our discussions.
So: Node representation, fields in core, data API, data rendering, database abstraction. Suggest an order of events.
Comments
wed evening
are folks going to stay the night on wednesday or shall we start heading for airport at 5pm?
[Moved to Logistics]
[Moved to Logistics]
We should be careful not to
We should be careful not to put the cart before the horse. We should not start talking about solutions until we talk about what our target is. What characteristics would a good architecture have? What exactly do we want to accomplish with our changes? What are some criteria we can use to help us tell which solutions are taking us in the right direction? If we just dive in and start talking about possible solutions without identifying our goals, we're likely to go round and round...
So I'd put this as the first topic on the agenda.
A lot of this stuff could be
A lot of this stuff could be broken up and worked on by smaller groups in the mornings. An API for fields in core. A new structure for nodes (or primary objects). Lots of possible sub-groups here.
The hard part will be Monday morning before we have our group meeting to get organized, so maybe leave Monday morning for personal stuff and plan to work in small groups Tues and Wed mornings at Panera (see my post in logistics) or our hotel rooms, or wherever.
can we do all that in 3 days?
we might need to pare down barry's list if we want to ensure success. it would be nice to have some proof of concept code when we leave this meeting.
my first thought is to move rendering off the table, which also moves "web services api" off the table since thats really about rendering the object using json, html, xml, etc. i am sad to propose this though. maybe it is isolated enough that we can do it in parallel.
if i had to propose another giant to slay, it might be 'fields in core'. then we could focus hard on the loading/saving objects (i.e. nodes, users, terms, ...).
on second though, fields in core
if we poll the community, 'fields in core' would rate highest onn barry's list. maybe we should make a list of minimum list of todos and focus there.
Field yes, but
while it'd be great to discuss fields in core, on Crell's ORM post we discussed that it'd be better to code a data API and implement file API on top of it -- and do no more for Drupal 7. So far, every big subsystem we had needed more than one release to get it right and it might be good to not fsck up the node subsystem. Of course it might be different exactly because of this meeting...
I might be biased :-) but I
I might be biased :-) but I also think that 'fields in core' would be a community 1st pick. Probably because it's one of the less technical / most user-facing items on the list.
IMO, one of the key points of this meeting would be to see how fields in core tie in (or not) with architectural items like ORM and data API, and figure out dependencies.
If we find fields in core for instance have little sense without Thingies, and this is too much for D7, then at least we have something to say to the public waiting for 'fields in core' to happen :-)
If we find the subjects to be pretty much orthogonal, well, some discussion and planning about 'fields in core' would not be superflouus anyway...
No mornings for me
I will be focusing on my day job until 1pm-ish daily, so I won't be able to do anything in the morning. I agree with those who are saying plan first, code later. If all we get out of this meeting is a solid architecture doc, I'd consider that a success.