Hello Larry, I managed to sneak my proposal in this morning (I've been having computer problems for the last few weeks). If you fancy joining me, it's here: http://barcelona2007.drupalcon.org/node/700 I know there's a lot to think about, but it would be nice to somehow come up with a clearer path to getting this sorted out, I've been looking at this: http://drupal.org/project/openresort which is okay, a good solution, but I would hope to get a better more scale-able solution if it's possible. Cheers Wednesday, August 8, 2007, 3:50:12 PM, you wrote:

I have done several reservation systems recently, actually, although not in Drupal. It's a problem-space that is begging for a generalized solution (Drupal or otherwise), and something I've been giving some thought to in the back of my head on a conceptual level. Definitely count me in for any such session.

--Larry Garfield

On Wed, 08 Aug 2007 13:49:47 +0100, Martin Frost <devel@fronbow.co.uk> wrote:

...

(not sure whether this is on-topic?)

Hi All

I'm interested in holding a brainstorming session on booking systems, but I'm not sure on what they involve! (other than a group of developers trying to come up with ideas!)

I have a need to come up with a room booking system (and this was a part of my cvs application) for work, but I also want to abstract it so that it becomes (almost?) a booking system api.

If I can successfully map out this idea, I envisage a booking system api that would then have 'bolt-on' or contributed modules that would extend it to cover meeting rooms, seats on an airline, hotel rooms, etc. And where the need arises for ecommerce, this would also be an 'added feature' not a requirement.

Currently we (http://extra.shu.ac.uk/cse) use a thing called iCalScheduler (http://sourceforge.net/projects/icalscheduler) - but I hacked it to work within phpBB as I originally used phpBB as a framework.

But I'm now using drupal (and have been since v4.6) and obviously want to get it integrated without the hassle of phpBB. (this is the only thing that's holding me back from totally drupalising the site)

I know it's viable, I just think I need some other like-minded developers to flesh it out with; and I also think drupal would benefit!!

Can anyone help, and would you be interesting in helping me get my head around this?!

Cheers

(sorry for rambling, see *note to self*!)

-- _fronbow_ devel@fronbow.co.uk aka Martin in the Real World(tm)

note to self: never drink on an empty stomach! Or have _that_ much at dinnertime when you're (supposed to be) working

-- Best regards, Martin Frost mailto:devel@fronbow.co.uk

...

I have a need to come up with a room booking system (and this was a part of my cvs application) for work, but I also want to abstract it so that it becomes (almost?) a booking system api.

How about this: an API that allows dimensions, locations, and status to be added to nodes, users, products, or whatever kind of object a developer wishes to create. A dimension would have two properties: a unit of measure and a direction. A location would have a start point and an end point in all the dimensions of the object. The status of the location would consist of other relevant properties. Using the room booking system as an example, a hotel would have at least two dimensions. Time would be the first dimension. It's direction would be towards the future and be measured in nights. A hotel would also have a dimension measured in rooms. Locations would be room-nights. They would have a start and end point (check-in and check-out) and a room number and quantity. Room-nights could have a status of occupied, vacant, or reserved. Another example would be floor space at an event. The vertical dimension could be measured in floors and the horizontal dimensions in feet. It could be divided into locations in advance, or customers could specify locations for themselves from the available space. Adding a time dimension would allow the same system to be used to rent space. Tracking inventory in a store could be done with just one dimension: quantity. Status could be ordered, on hand, or sold. An additional status could be added to track the condition of the inventory. Adding an additional dimension would allow quantity and status to be tracked for different batches of an item.