Meeting notes 2011 02 02

Inspiran proposed to talk about the next 3 items:

• status of community feedback
• technical roadmap - what are our knowledge gaps
• how to move forward

*** About point 1 ***

We were discussing about the feedback we were receiving from the community. Seldaek provided us some experience with magento in our issue's page: https://github.com/vespolina/vespolina/issues#issue/2 Then we have 'lufi', who mailed us with another use case and how magento handles it, so we take it into consideration. Briefly, the case is about having a product(e.g. A t-shirt) and a customer can choose some options for it like (color, size, etc). Also he explained us why does he consider it so tedious to maintain for the store owner.

23:16 < inspiran> Magento handles this case with "Configurable product".
23:16 < inspiran> A configurable product is a virtual product with a set of real
23:16 < inspiran> (simple) products which share some attribute (color & size) with differents values.
23:16 < inspiran> This implementation works perfectly but it means that for our example
23:16 < inspiran> (2 colors and 5 sizes) there is 11 differents products reference in the admin catalog.
23:16 < inspiran> Each product must created/configured/updated independantly.

We've been discussing a little this case and thinking some solutions.

*** About point 2 ***

We were discussing the possible components we are going to need. We created a wiki page (https://github.com/vespolina/vespolina/wiki/Ecommerce-architecture) listing them, and we are going to start completing them with their meaning, description, requirements, responsibilities, and how they can communicate each other.

The components we thought at the moment are:

• Process Engine
• Product Service
• Inventory Service
• Catalog Service
• Payment Service
• Fulfillment Service
• Notification Service
• Pricing Service
• Document Service
• Exchange Service
• Scheduling Service

We were discussing them very briefly.

*** About point 3 ***

Mainly, we are going to start completing the wikis for every components we were discussing. We think it's very important to receive suggestions and feedback for this. So we are going to consider every idea you can provide.

---

22:24 -!- inspiran [~void@78-21-100-215.access.telenet.be] has joined #vespolina
22:25 < inspiran> hello
22:53 -!- matias [~matias@host161.190-31-227.telecom.net.ar] has joined #vespolina
22:54 < matias> hello
22:59 < iampersistent> hello
23:00 < matias> meeting time?
23:00 < iampersistent> yes, looks like it
23:00 < matias> very good
23:01 < matias> hey, i just wanted to tell you, that i'm going to be not very active this month
23:01 < iampersistent> ok, that happens :)
23:01 < matias> i have a lot of exams this month
23:01 < iampersistent> ah, I see
23:02 < inspiran> in
23:02 < inspiran> matias, what are you studying for?
23:02 < matias> systems engineer
23:03 < matias> i'm just finishing with my major
23:03 < inspiran> ah cool
23:03 < iampersistent> awesome
23:03 < inspiran> and then you are a real man
23:04 < inspiran> did anyone hear from florian or alecs?
23:04 < matias> haha, it's supposed i'll be a real man
23:05 < iampersistent> no, I did see that his company has him focusing a day a week on the CMF project though
23:05 < inspiran> ah, where did you saw that?
23:06 < iampersistent> hmm, either the cmf list or channel, I cannot remember right now
23:07 < iampersistent> well, I started adding a few more use cases to the wiki, but didn't get very far
23:07 < iampersistent> well more of bullet points
23:07 < iampersistent> I'll try to get the rest of it up by tomorrow
23:07 < inspiran> ah great
23:07 < inspiran> you are refering to the Atheletpath use case?
23:08 < iampersistent> I'm referring to generic use cases that may or may not be Athletepath ;)
23:08 < inspiran> ok, sorry that i didn't had the time to put agenda points only
23:08 < iampersistent> its ok
23:08 < inspiran> here i have them, feel freely to add them later on:
23:08 < inspiran> 1)status of community feedback
23:08 < inspiran> 2)technical roadmap - what are our knowledge gaps
23:08 < inspiran> 3)how to move forward
23:09 < iampersistent> an fyi, next week I may be limited in my availability for the meeting, i'll be at sflive :)
23:09 < inspiran> that's ok, you can do some PR about the project
23:09 < inspiran> ok, shall we start?
23:09 < iampersistent> so any thoughts on where we are now?
23:09 < inspiran> ----------
23:10 < inspiran> first of all, let's discuss where we are now
23:10 < iampersistent> :)
23:10 < inspiran> a week ago i communicated about the project on the mailinglist
23:10 < inspiran> for now we had following feedback:
23:11 < inspiran> -seldaek commented on the RFC: https://github.com/vespolina/vespolina/issues#issue/2 23:11 < inspiran> -Daniel Richter (richtermeister) - commented on the mailing list
23:12 < inspiran> i mailed him and it looks that is interested in participating
23:12 < iampersistent> I think the initial feedback was pretty good
23:13 < inspiran> it was indeed
23:13 < inspiran> about Daniel Richter, he created http://www.skinmedica.com/ 23:13 < iampersistent> I think it is hard to get people really on board in the early stages, but I think getting the additional insights was a good thing
23:13 < inspiran> yep i agree, and some PR is always good
23:14 < inspiran> i think he could help us on the shopping cart stuff
23:14 < iampersistent> that would be good
23:14 < inspiran> also, the site he made is pretty slick and clean, good quality
23:14 < inspiran> (also the check out process)
23:15 < iampersistent> I need to spend some time on it, I just hit the page quickly
23:15 < inspiran> i'm goig to be honest, i still need to process all community feedback
23:15 < inspiran> ok, next we have 'lufi', who mailed me with his use case
23:15 < inspiran> i'll copy paste the mail:
23:15 < inspiran> --------
23:15 < inspiran> So
23:15 < inspiran> I'll try to summarize the use case, explain how magento handle it (and why it's a pain).
23:15 < inspiran> Clothing brand sell product which are configurable.
23:15 < inspiran> For example a t-shirt can be available in 2 colors and 5 sizes.
23:15 < inspiran> On the frontend
23:15 < inspiran> The customer wants the t-shirt to appear one time in his catalog/ product list.
23:15 < inspiran> On the product details you can choose between available options (colors and sizes for instance).
23:15 < inspiran> Checkout is done on a particular configuration
23:16 < inspiran> On the frontend
23:16 < inspiran> The customer wants the t-shirt to appear one time in his catalog/ product list.
23:16 < inspiran> On the product details you can choose between available options (colors and sizes for instance).
23:16 < inspiran> Checkout is done on a particular configuration
23:16 < inspiran> On the backend
23:16 < inspiran> Stocks (SKU and quantity) must be on the real product (a t-shirt with a particular color and size) Some other attributes are shared between the available options Promotions and analytics can either concern real or "virtual" product
23:16 < inspiran> The Magento way.
23:16 < inspiran> Magento handles this case with "Configurable product".
23:16 < inspiran> A configurable product is a virtual product with a set of real
23:16 < inspiran> (simple) products which share some attribute (color & size) with differents values.
23:16 < inspiran> This implementation works perfectly but it means that for our example
23:16 < inspiran> (2 colors and 5 sizes) there is 11 differents products reference in the admin catalog.
23:16 < inspiran> Each product must created/configured/updated independantly.
23:16 < inspiran> => Nightmare for store owner to use this (what about uploading the same photos for each 5 sizes with the same color?).
23:17 < iampersistent> well, I think with mongodb we can definitely handle cases like that in a friendlier way
23:17 < iampersistent> but, maybe this needs to be one of the first POC that we do
23:18 < inspiran> could be, the thing is, i see him mentioning several things at once
23:18 < inspiran> -the sucky EAV model, which we fix with mongo
23:18 < iampersistent> you know I've been thinking, maybe we need to a search to find common problems with the various ecommerce systems and look at how we can avoid some of those problems
23:18 < iampersistent> right
23:19 < inspiran> -the SKU issue
23:20 < inspiran> meaning: do you give each variation of your product a different SKU (eg. tshirt1-red , tshirt1-blue) or do you use the same SKU for different variations
23:20 < iampersistent> maybe we do a matrix for the skus for the various options?
23:21 < iampersistent> maybe we let the admin choose which way, but provide both
23:21 < inspiran> we need to provide both options
23:21 < inspiran> then he mentions another problem:
23:21 < inspiran> mass product maintainance
23:22 < inspiran> actually, it's related to the SKU issue, because if you use different SKU's for variations, you usually will have individual pictures
23:22 < inspiran> but i can imagine that for 15 variations, you'll just use the same picture
23:23 < iampersistent> or pic of blue, pic of red that goes on all sizes
23:23 < inspiran> and you don't want the user having to upload 15 pictures
23:23 < inspiran> indeed
23:23 < inspiran> so the question is: how do you relate them correctly so you can reuse the image
23:23 < inspiran> or supply the user some functionality to mass link them
23:25 < iampersistent> well, maybe you have a default image for the product, then perhaps you organize the attributes in a hierarchy or a matrix, x axis or parent would be the color, y axis or child would be size
23:25 < iampersistent> with a tree start at the leaf and work your way up, if there is an image in the size node, use it, if not, get an image from the color node, if that isn't available use the default image
23:25 < inspiran> yeah, that could work, but keep in mind that some products could have more than 1000 variations
23:26 < inspiran> ah, i see, like that, that could be an approach
23:26 < inspiran> but product configuration - product composition are typically hard topics in ecommerce
23:26 < iampersistent> right, well think we have to have some type of system to have a default and get more detailed on the variation
23:27 < inspiran> eg. composing different products into a new product with its own SKU
23:27 < iampersistent> maybe thats something that for "standard" cases we write a wizard for
23:28 < inspiran> yeah
23:28 < matias> maybe we can provide something independent for saving images
23:28 < inspiran> such as?
23:28 < matias> you probably have seen this before
23:28 < matias> like an upload library
23:29 < iampersistent> it would still require some thought on the admin end, but if we have hints of smallest group of options being the parent node and work out from there, I think if some one has something that complex, they'll to put some thought into organization, if nothing else just for inventory purposes
23:29 < inspiran> iampersistent, for this we'll need feedback for sure from the community
23:30 < inspiran> the approach is here to look at how for instance magento is doing it and then look at the forum what he folks really want
23:30 < iampersistent> I agree, but I think we'll have to make some type of POC to get feedback on something like that
23:30 < inspiran> yup, but i'm not sure that is the first thing we need to do
23:31 < inspiran> matias > you mean first uploading some images and then linking them?
23:31 < iampersistent> right and I think that Bernhard had a good point of looking at projects, outside of php also. I know I've been looking at the IBM java stuff for api (I can't remember what it is called right now)
23:31 < matias> that's right inspiran
23:31 < inspiran> iampersistent > i already contacted him
23:32 < inspiran> i've asked him if he could help us at some point, he looked interested
23:32 < iampersistent> cool, the more eyes on this, the better
23:32 < inspiran> yup
23:33 < inspiran> matias> i actually like that idea
23:33 < matias> i saw this in a couple projects
23:34 < matias> i think wordpress works that way, and apostrophe too
23:34 < inspiran> yup, like the apostrophe way of working
23:34 < inspiran> the allow you to link to flickr, youtube, vimeo, ...
23:35 < inspiran> *they
23:36 < iampersistent> anything else about the feedback?
23:36 < inspiran> for now that's it, i'll try to go to sf hack day @ paris and talk to some falks
23:37 < iampersistent> I'll be at hack day sanfran, well until the superbowl :)
23:37 -!- inspiran [~void@78-21-100-215.access.telenet.be] has quit [Read error: Connection reset by peer]
23:37 < matias> iampersistent> you are very lucky living so close to the conference
23:37 -!- inspiran [~void@78-21-100-215.access.telenet.be] has joined #vespolina
23:37 < iampersistent> yeah, its nice
23:37 < inspiran> hmm, got disconnected
23:38 < inspiran> [21:36] for now that's it, i'll try to go to sf hack day @ paris and talk to some falks
23:38 < inspiran> [21:37] i hope you can do the same @ sf?
23:38 < inspiran> [21:37] * Disconnected
23:38 < iampersistent> I'm glad we are having them in the US now
23:38 < iampersistent> now, to get them in South America :)
23:38 < matias> i'm really kind of jelous
23:38 < matias> hahah
23:38 < matias> not soonly probably
23:38 < iampersistent> inspiran I'll be at the hack day SanFran
23:38 < inspiran> matias> do it brasil :)
23:39 < inspiran> rio de janeiro
23:39 < matias> yes, anywhere, but i don't see it comming
23:39 < matias> i spect somebody upload it soonly in vimeo
23:40 < iampersistent> hmm, I wonder if anyone is planning on that. I should take my camera, just in case, although it keeps shitting out on me :(
23:40 < inspiran> iampersistent, take your mic with you and do some singing
23:41 < iampersistent> :)
23:41 < inspiran> i would like to go to sf, but have for now no budget for that

23:41 < iampersistent> I understand
23:41 < inspiran> ok
23:41 < inspiran> next topic :)
23:41 < iampersistent> yes
23:41 < inspiran> [21:08] 2)technical roadmap - what are our knowledge gaps
23:42 < inspiran> for the functional side we already have some good idea what we need, and know how to find more information
23:42 < inspiran> but from the technical part we need to start to understanding which components the ecommerce solution should have
23:43 < inspiran> first we need to understand the high level components, and secondly understand how they should be related
23:43 < iampersistent> any ideas on how we approach this?
23:44 < inspiran> i would propose to create a wiki page
23:44 < inspiran> listening all components which we think are needed and later on indicate whether or not it needs to be implemented in a POC
23:44 < iampersistent> what shall we call it (I'll create it right now)
23:45 < inspiran> maybe create a main page 'ecommerce-architecture'
23:45 < inspiran> and for now put them there, for each component we create than individual pages
23:46 < inspiran> components which we need:
23:46 < inspiran> -(business) process engine
23:46 < inspiran> -product/service catalog
23:47 < inspiran> -payment service
23:47 < inspiran> -shipment service
23:47 < inspiran> -pricing service
23:47 < inspiran> -notification service
23:47 < iampersistent> how about fulfillment instead of shipping?
23:47 < inspiran> -printing service
23:48 < inspiran> yup, even better
23:48 < iampersistent> does pricing belong with product? if not, how is it separate?
23:49 < iampersistent> And what is printing service?
23:49 < inspiran> the product catalog should use the pricing service, but the check out process would also need the printing service as well (eg. for

              determining additional fees)
23:50 < inspiran> printing should be all relating do printing, which would be called by the fullfillment service
23:50 < inspiran> (eg. to create a .pdf and attach it to a mail)
23:50 < inspiran> or if you ship something, you need to a add a delivery document
23:50 < inspiran> and maybe an additional document for customs
23:51 < iampersistent> how about we call it document service then?
23:51 < inspiran> hmm
23:51 < inspiran> yeah, is better
23:52 < inspiran> the notification service could call the document service to generate a summary of the sales order and have it attached to an email
23:53 < iampersistent> should the product include catalog and inventory, or should those be separate services?
23:53 < inspiran> separate
23:54 < inspiran> example use case: product catalog is maintained in Vespolina, but for inventory web services are used with an ERP system
23:54 < inspiran> and to continue the use case: billing is handled by the ERP system aswell
23:55 < matias> then you have another component: Inventory
23:56 < iampersistent> https://github.com/vespolina/vespolina/wiki/Ecommerce-architecture

23:56 < inspiran> i'm not sure we should it call inventory, but for now it will do
23:57 < inspiran> (eg. i had warehouse inventory in mind, but that's maybe too specific)
23:58 < iampersistent> yeah, I think that would be a specific type of inventory
23:58 < inspiran> indeed
23:59 < inspiran> i also think we'll need something like component managers
23:59 < inspiran> eg. you could have two inventory components
23:59 < iampersistent> right
23:59 < inspiran> one for warehouse inventory, and maybe another one for downloadable components
23:59 < iampersistent> Maybe the components shouldn't be called Xxxx Service, just Xxxx
Day changed to 03 Feb 2011
00:00 < iampersistent> The service would handle the components
00:00 < inspiran> example use case: you buy some Cisco hardware (WH inventory) and you download some software which you additionaly pay such as management

              software ( download inventory)
00:02 < iampersistent> anything else on point 2?
00:02 < inspiran> yes, the feasibility on using ezcomponents WF engine
00:02 < inspiran> matias?
00:03 < matias> sorry, i don't see the download inventory
00:03 < matias> i don't get it
00:03 < matias> why we need that
00:04 < inspiran> for me this would be something virutal
00:04 < iampersistent> it would not be an inventory in the normal sense

00:04 < inspiran> which could be linked to different CDN's (content distribution network)
00:04 < iampersistent> it may just be the handler for the downloads
00:04 < inspiran> and when you call checkAvailability('productX'), it would check if there is a server that can handle the request
00:05 < matias> very good
00:05 < inspiran> it could hint the server to prepare the download link
00:06 < inspiran> (eg. in apache, create symlinks, maybe transfer data, whatever)
00:06 < matias> i understand now, i was seeing it as they theached me in the highschool
00:06 < inspiran> ok :)
00:06 < inspiran> matias,did you get some time to look into the workflow stuff?
00:07 < matias> i didn't do anything else
00:07 < inspiran> :(
00:07 < matias> i just preapared the example, and i made it work
00:07 < inspiran> did you publish it somewhere?
00:08 < matias> the example?
00:08 < matias> yes, i posted in the wiki,
00:08 < matias> did you see it?
00:08 < inspiran> hmm, no
00:08 < inspiran> what is the link?
00:09 < matias> https://github.com/matubaum/vespolina/wiki/Working-with-the-ezc-workflow 00:10 < inspiran> ah, that's why i did not find it!
00:10 < inspiran> matias, sweet, we'll need to look at it

00:11 < inspiran> maybe push it to the main wiki?
00:11 < iampersistent> I'm looking at doing that right now
00:12 < matias> yes, that's why nobody've seen it
00:12 < inspiran> iampersistent> maybe also rename the file
00:12 < iampersistent> I'm going to put it in with the process flow page
00:13 < inspiran> we should have a proof of concept part
00:13 < inspiran> maybe link it from the technical architecture page
00:14 < inspiran> 1)heading with 'components's and then 2)POC of components
00:14 < iampersistent> ok I'll put it in the Process engine page, hopefully thats not too deep,
00:14 < inspiran> yep, even better
00:14 < iampersistent> Maybe we also have a POC page though, just to make it easier to get to
00:16 < inspiran> yup
00:16 < iampersistent> point 3?
00:17 < inspiran> 3)how to move forward
00:18 < inspiran> i see that we are getting on a good roll, so we'll need to start thinking about each component
00:19 < inspiran> i think for each component we should listen a)fundamental requirements b)nice to haves requirements c)implementation approaches (which we

              should then put as RFC by the sf2 community)
00:22 < iampersistent> matias, I copied your page over to the main wiki, so if you update it, do it on the main wiki also, if you would please
00:22 < matias> no problem
00:24 < matias> i don't see the graph
00:25 < matias> i take it

00:25 < iampersistent> yeah I was just getting ready to ask that, I don't know how to add the images
00:27 < inspiran> we forgot a component
00:27 < iampersistent> its a wiki, add it ;)
00:27 < inspiran> exchange service (import / export)
00:27 < iampersistent> oh yeah
00:28 < iampersistent> actually in one of my use cases I need to put up
00:28 < matias> done
00:28 < iampersistent> cool, exchange service added
00:29 < inspiran> heh, we are already on 29 wiki pages and 22 followers
00:29 < iampersistent> matias how? (feeling a little dumb right now)
00:30 < matias> haha, it was hard to me too
00:30 < iampersistent> but you figured it out :p
00:30 < matias> you just cant do it from the web
00:31 < matias> you have to clone the wiki page
00:31 < inspiran> iampersistent > based on your subscription use case, i woul suggest that we would have some kind of a background job management service
00:31 < iampersistent> btw, I've been adding bread crumbs to the top of the wiki pages, it make break at some point, but I think the convience is good to

                   have
00:31 < matias> add the image in the same directory and push it
00:31 < iampersistent> oh, ok
00:31 < iampersistent> I thought I could do it from here
00:31 < matias> yes, mee too

00:32 < inspiran> iampersistent> saw it, looks ok
00:32 < matias> i don't know if there is other way
00:32 < iampersistent> Scheduler service?
00:32 < iampersistent> don't like it
00:32 < iampersistent> scheduling service?
00:33 < inspiran> better
00:33 < iampersistent> done
00:33 < inspiran> or background job service
00:33 < iampersistent> I'm trying to stay down to one word :)
00:34 < inspiran> scheduling could be a service which would determine when a background job is scheduled
00:34 < iampersistent> guys I need to wrap up, is there anything else we need to talk about today?
00:34 < inspiran> for me it's ok, i'll have a look at your use cases
00:34 < inspiran> maybe finish with a todo list?
00:34 < inspiran> me: process community feedback and read use cases from iampersistent
00:34 < iampersistent> sure,
00:35 < inspiran> iampersistent: start writing some description on components?
00:35 < iampersistent> I need to finish the use cases
00:35 < iampersistent> yes I'll do that
00:35 < matias> that is
00:35 < inspiran> iampersistent, anyhow, everybody will need to add data to it
00:36 < matias> we have to start writing what every component means, they responsabilities

00:36 < inspiran> yup matias
00:36 < inspiran> you can also help if you would like
00:36 < matias> so probably we are going to discover more components we need
00:36 < inspiran> matias, absolutely
00:36 < iampersistent> yes probably so
00:36 < inspiran> for instance, the notification service would depend on a 'templating service'
00:37 < iampersistent> I think we should all pick a ecommerce package to look over to learn from
00:37 < inspiran> which could merge a predefined text template with the actual data
00:37 < matias> I was thinking on a reporting service, probably it can be included in document service
00:37 < inspiran> iampersistent > yup, but that's for next week
00:37 < iampersistent> ok
00:37 < inspiran> first let us describe the thing we think is needed based on the use cases we have
00:38 < inspiran> after we've all component requirements, we start looking around
00:38 < iampersistent> ok, makes sense
00:38 < iampersistent> I won't have time to do both any way :)
00:38 < inspiran> i thought so, let us keep things simple
00:38 < iampersistent> I don't know how to do that, it a weakness
00:38 < inspiran> matias > yup, but for me that is not yet needed
00:38 < matias> my case, i mean it, i really going to start being absent this month
00:39 < inspiran> and honestly, there are some opensource tools which are good for reporting
00:39 < inspiran> check http://www.pentaho.com/

00:39 < matias> maybe
00:39 < iampersistent> thats fine, do what you can and don't worry about it.
00:39 < iampersistent> lets start utilizing the google group a little more so we can exchange information, even if we can't make it to the meeting
00:40 < inspiran> yep, that's the last thing
00:40 < matias> hey pentaho looks interesting
00:40 < matias> have you ever used it
00:40 < matias> ?
00:40 < inspiran> we should really start using it
00:40 < inspiran> no, but i know it's existance :)
00:40 < inspiran> matias > so it's maybe better to check how we could interface with it
00:40 < iampersistent> anyone have time to put a summary together of today's meeting with log?
00:41 < iampersistent> if not, I'll add it to my list
00:41 < matias> where are we doing that
00:41 < iampersistent> I figure start a page on the wiki with the meetings and link each meeting off of that
00:41 < inspiran> matias > interested in writing a small meeting summary and putting it on the wiki?
00:42 < matias> not really :)
00:42 < matias> but i can do it some times
00:42 < iampersistent> I like it, be honest :)
00:42 < iampersistent> I'll take it this week
00:42 < inspiran> iampersistent > feel free to do it, but don't kill yourself with your workload
00:42 < inspiran> ok, then we can finish the meeting
00:43 < iampersistent> awesome, good work guys
00:43 < inspiran> great
00:43 < matias> ok, i have to go too
00:43 < iampersistent> later
00:43 < inspiran> ok , bye bye matias
00:44 < matias> i have no problems to write the summary today
00:44 < matias> do u want me to do it?
00:44 < inspiran> i propose that matias creates the summary and mail it to iampersistent to complete it
00:44 < inspiran> *mails
00:49 < matias> i'll write it on the wiki, then you can edit it to correct my orthography that i know how it sucks
00:50 < inspiran> great
00:50 < matias> well, see you
00:50 < matias> try to read my workflow wiki page
00:51 < matias> bye
00:51 < inspiran> cya