Hmm... I'm not really sure how to address the issue. There are several things involved... first, uBrowser is being taken out b/c it just wasn't helpful. Somewhere along the line I actually made an alternate interface in core. TAPIr isn't being taken out, it's being folded in to remove the external dependency. It just isn't something module packages are going to use as is, and we barely use it in Ubercart.

Workflow-ng is being moved to Rules. A name change and reworking doesn't bother me and wouldn't keep me from using it. Mostly it comes down to needing something different, needing it quicker, and needing to remove the external dependency. I don't think anything we'll do would make an Ubercart site incompatible with Rules, but I do think that some things we need to do would be a lot harder just using Rules (insomuch as it is similar to Workflow-ng).

One example is evaluating stand alone condition sets that are setup through a form embedded into the taxes administration. Right now, someone has to create a tax rule then browse away to the Workflow-ng overview page and add rules to a tax to limit its application. This is unnecessarily complex and has caused plenty of headaches for folks setting up shipping. Doing this is already possible w/ our core conditional actions parser, and the UI is well underway.

Refer to point 2 in this post. We really appreciate all the work fago put into Workflow-ng and were to have found it in our early development of Ubercart. I just don't think it's good for Ubercart in the long run to outsource such an important part of the project.

Totally possible. We'll be sure to post documentation with the 2.x release.

Hi,

In understand both opinion of Ryan and Fago

I just would add that, even if the workflow integration brings some unwanted step for configuration (example shipping : You add the shipping quote, and then, you activate the workflow rules and define the conditions). Workflow allowed to define some usefull and complex conditions/actions without coding one single line.

I wonder, if Ubercart get rid of Workflow/rules, if it will be able to provide all the possibilities workflow already provide. Some workflow conditions and actions, not specially related to ubercart are very usefull. For example, get the user role to calculate a tax rate etc...

In addition, a lot of modules began to integrate workflow-ng, they all add some new actions, conditions, without the need for ubercart to add a single line of code. Example the organic group or nodeprofile integration, I don't use them with ubercart ATM, but it could be usefull for people to create a relation between a group and ubercart, and workflow is a good gateway for that.

If ubercart begin to write his own solution, this would involve that these module have to write one more integration to beeing usable with ubercart or ubercart to write extra code to beeing usable with these modules.

EDIT : I would like that, more than workflow, there is another dependencies/integration that it would be judicious to remove, it's the imagefield integration. This module took too much time to go out, and the issue queue for 6.x pratically seems dead. A very good alternative, more more reactive grown up, it's filefield with filefield image.

Hi,

As I said before, I completely understand your choices, which are completely viable. You never know, maybe fago you will be crunched by a tank tomorrow, if it's the case, who will develop rules module ?

The fact to provide minimum function in ubercart core and provide the possibilities to extend them with third party module is probably the best choice for usability and extensibility, but this is the choice that bring the most work for you

But be carefull, by providing too much out of the box feature, it finally could be more difficult to personalize ubercart than directly provide an integration with a less "out of the box" module, but more powerfull, and the product listing is a good example for that.

Imagine that an user, that was firstly happy with the core listing product now want something that is not possible with it, and it can be a simple thing, like adding the product SKU in the listing or providing an AJAX pagination.

He will have 2 solutions : coding ajax pagination in a custom module for the default product listing, or reproduct the listing with views, that already provide ajax pagination. Using views will be more simple for him but will involve to create the view, theme it as the product listing he had etc.... Finally, it was more simple to directly create the listing with view, and just add the SKU column by adding it under the field section of views.

Quite likely. We aren't planning a great divergence at least for the foreseeable future.