+1

+1

+1

+1

Will you continue working on this problem?

I've done some booking functionality here:
http://drupal.org/project/booking_timeslots
Maybe somebody will be interested,
but it's still under development and many things to do.

Though I believe that Booking Timeslots and Bookings API do not really provide the same functionality - it's quite a different approach to a similar problem.

Related to the thread: In the long run Bookings API will support node-bases resources including CCK-integration.

Brilliant news - really looking forward to seeing this project move forward. Personally very keen to use uc_node_checkout as a way to use Ubercart to bill for appointments.

Just spotted

for deciding between multiple users on the best times for a booking (or meeting) - ability to integrate or duplicate (aaaargh!) this functionality would be amazing. Not checked it out yet so not sure if it is CCK based or on it's own.

Doh - Just read the module info. Dudel uses CCK date field so yay?

How/Why would you like to integrate something like this into a bookings module? (This is a real question, ATM I don't understand the why ;) )
If you tell me, what you need/want, we could perhaps provide it.

I may have got the wrong end of the stick but I'm assuming that the CCK/Nodes integration involves both using nodes as the resources as well as nodes as the bookings themselves. If the bookings are nodes and use a CCK date field, it would be advantageous for multiple users to be able to input multiple choices for making a booking using the existing Dudel code.

This is straying off a little but I am personally trying to achieve a goal of allowing end users (customers) to book other users (engineers). The users that can be booked would have FeedAPI pulling in an iCal feed of free/busy times (nodes) that would hopefully provide conflict resolution using bookings API if it used nodes as the bookings. At the same time, I'd like to use the Dudel interface so that multiple users (stakeholders in a project) to select a mutually agreeable time for the booking. I'm assuming that without some form of integration, I cannot simply install both Dudel and the future BookingsAPI and bingo it works.

I am not 100% sure how to exactly refactor Bookings API / Public Bookings into using nodes - but so far the plans would include bookings and resources as nodes, yes (performance issues may change this opinion).
I want to add some functionality that would allow administrators to set some "conflict resolving rules" (e.g. sorting resources into families and providing the user with the choice of a different resource of the same family (say: Beamer#2 instead of Beamer#1) and/or adding some kind of "number of devices present"-field (resource: beamer, 12 pieces total, 8 available)).

I did not have a (thorough) look at Dudel, so I cannot tell how much work an integration will be. I will have a look at it before really rewriting the code, to ease any integration efforts. But I cannot promise an "out of the box functionality" - sorry. Integration of "multiple owners of a booking" would be possible (e.g. adding a multi-select field 'owner'), as would an "hook_resolve_conflict" (however it will be named).
If you have any ideas, what you would need in order to integrate with Drudel/FeedAPI, please don't hesitate to write them! I promise to try my best, to keep "integration with other modules" in mind, so that it will be easy to integrate Bookings API / Public Bookings with other modules.

Hello there,
I gave Bookings API / Public Bookings a try and I can say it looks very promising ! Especially very good views integration very nice! keep on great work

...so far the plans would include bookings and resources as nodes, yes (performance issues may change this opinion).

In my opinion this feature together with increased calendar integration is THE key to make it really fly and gain popularity..

I am planning how to best integrate Bookings API with e.g. the calendar.
We are going to use "nodes" as resources - but how to save Bookings?

It might be more efficient to stay with a home-brew system - another alternative would be using the Event API. Opinions?
Using Event would mean, that the Bookings API would add another prerequisite (Event), which would make it a bit bigger and less flexible. On the other hand event provides a native integration with Calendar and stuff.

Would bookings as nodes not be good then? I've probably missed something but wouldn't it be the most flexible way to do it for multiple use cases? I wouldn't want to see a dependency on Event - that would get quite confusing for many newbies (myself included) or clients with admin access.

Events are a kind of nodes - so bookings would still be based on nodes (with all the flexibility it provides).

Thanks for the feedback - I'll have to look into Calender to see, how much work a separate integration would be.

One would not believe it - this is in work.

6.x-3.x-dev now uses node-based resources instead of the previous custom-type. Bookings still are custom-typed, but I'll change this in the ongoing refactoring. Please be aware though that 6.x-3.x ist NOT a stable release by any means. It's not even a pre-release or an alpha - its my personal "work repository". A commit might not even compile at any given time...
If you'd like to test it - be my guest. But it really is NOT usable at the moment.

Just in case you were feeling alone in your quest, here's a big

wooot

from me regarding the new progress with this.

---edited to increase woot factor

*blush*

*smile*

....keep up the good work!