If the parts are well chosen, then the prices will serve as a rough guide, which is all they were intended to be. Exchange rates fluctuate too, but IMO it's perfectly fine to put them on disk and use them as a guide.
The process is likely to be something like:
1) go through and choose stuff
2) get output BOM
3) upload to supplier
4) look at availability and price
5.1) correct details by hand and order
OR
5.2) fix up source data and run through process again
However, if the API is clean and useful, such a thing would be great! :-)
Fred.
FreeBOMBS
Re: FreeBOMBS
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
Re: FreeBOMBS
It's an isolated database for a good reason: flexibility. Electronic components are just one mode of operation. An external script to update the components is fine and yaml is an easy format to parse and generate both for humans and software. Any meta-information can be added to both suppliers and components to help an external script update info, if needed.nitrousnrg wrote:Now I see the flaw. It took me a while to realize it doesn't communicate with any internet service, I got kind of upset when I wasn't able to find the segment of code that does something like an http request.
They are a rough estimate in this case, unless updated manually or by a script periodically.nitrousnrg wrote:Relying fields like price and availability into an isolated database is no good, prices changes and components goes off of stock very fast.
It sure is a nice add-on, but not an essential core part. JSON structures are contain equivalent structures/types as YAML. They both are convertable into each other and both are easy to parse and handle. The big difference is that human-readability/writeability of JSON sucks.nitrousnrg wrote:So, I registered at octopart.com, in order to get unlimited access to their search engine API. You don't have to register, unless you are going to do more than a 100 searches per day.
http://octopart.com/api/v2/parts/search?q=1N5364BRLG
will search for the part number 1N5364BRLG (a zener). Click over it to see the http response.
This follows JSON, I have no clue about what it is, but you might find it useful.
It's fine to build an external script to update things like this for electronics components, but the freebombs itself can be used for any kind of parts and much different goals than this first usage scenario.
Including automatic database updating in the selector/viewer app wouldn't make sense, it's easy to re-read the db after updating and it wouldn't even mess up the user's session (much) as long as the ID's and the configuration stay the same.
I could do a separate script, which would reside in the freeems-puma-spin1.bombs repository and would update parts from octopart. It's however nothing I'll include in the main freebombs repository, because a feature like that is entirely optional and would only make the app less generic and more complex.
Even if one wants to replace the source engine from yaml to anything else, it's a fairly easy job, as long as the data structures are similar. There are no hard dependencies on yaml except for the couple of lines that reads its contents and uses the YAML library to convert it into Arrays, Hashes, Strings, Numbers and Booleans.
Re: FreeBOMBS
Other good reasons are tracking of changes (via repository) as well as reliability (relying on external parties directly makes the system only as reliable as the sum of the external dependencies).Jammi wrote:It's an isolated database for a good reason: flexibility.
Re: FreeBOMBS
I wish people understood me when I said that! I may have to borrow your words in future!Jammi wrote:because a feature like that is entirely optional and would only make the app less generic and more complex.
+1 to the change management! Git control is EXTREMELY POWERFUL, don't underestimate it, people!Jammi wrote:Other good reasons are tracking of changes (via repository) as well as reliability (relying on external parties directly makes the system only as reliable as the sum of the external dependencies).Jammi wrote:It's an isolated database for a good reason: flexibility.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
- nitrousnrg
- LQFP144 - On Top Of The Game
- Posts: 468
- Joined: Tue Jun 24, 2008 5:31 pm
Re: FreeBOMBS
Oh, don't worry, If its not in your plans, don't do it. I just still don't get the use of writing a complete database for this situation, so I was trying to avoid doing so.Jammi wrote:I could do a separate script, which would reside in the freeems-puma-spin1.bombs repository and would update parts from octopart. It's however nothing I'll include in the main freebombs repository, because a feature like that is entirely optional and would only make the app less generic and more complex.
Xess corp has something like a database for they Xula board. Its powered by an user script that has the part numbers and you choose which supplier you wil use. It checks for avaliability as far as I remember. Its for Eagle, though.
Its about time to push something... tried to add a supplier, but it expects that every component will have the part number for both suppliers, so I'll just replace the part or add a replacement.
Marcos
Re: FreeBOMBS
That sounds like a bug or flaw to me. That will regularly not be the case. Jammi, comments?nitrousnrg wrote:tried to add a supplier, but it expects that every component will have the part number for both suppliers, so I'll just replace the part or add a replacement.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
Re: FreeBOMBS
Marcos' assumption is correct, the solution to it too.Fred wrote:That sounds like a bug or flaw to me. That will regularly not be the case. Jammi, comments?nitrousnrg wrote:tried to add a supplier, but it expects that every component will have the part number for both suppliers, so I'll just replace the part or add a replacement.
Yes, it expects each part to be available from every supplier listed and if not, a replacement supplied.
I'm open to suggestions about how to handle missing parts gracefully, list of supplier preferences, which would build several BOM's? Something like that might make the software pretty complex internally as well as for the user.
Possibility of bugs are likely too, because the multi-supplier mode hasn't been tested yet; there hasn't been any data to test on.
Re: FreeBOMBS
One temporary work-around would be defining one or several "null" parts, which would satisfy dependencies. It would have each supplier listed with price: 0 or something and defined as a fall-back for components that don't have alternatives within a single vendor's scope.
So, before I do any implementation work further, I'd like the mode of operation discussed throughly to map different alternative approaches of how to implement this stuff.
List of ideas:
So, before I do any implementation work further, I'd like the mode of operation discussed throughly to map different alternative approaches of how to implement this stuff.
List of ideas:
- A sortable list of suppliers in order of preference instead of the Preferences -> Supplier option, where currently is an option to choose a single supplier amongs many, each having all components in stock. One of the supplier options would be "I already have this component or I'll buy it from another vendor"
- For each component, a similar list, but only the suppliers with the part available would be listed as selection options. Others would be filtered out.
- Another mode, instead of sorting a list of preferred suppliers manually, would be a simple (from the user's point of view) "Optimize prize" mode instead. It would however need to take into account "shipping and handling" as a virtual component too, which makes it a bit more complex to implement.
- A proper, custom BOM widget instead of the crude ascii table in use currently.
- Vendor-specific specification syntax for the output.
- Each of these are individual pieces of software, which can be used zero, once or many times. Just the data fed to them matters (and the code processing the data).
Re: FreeBOMBS
This thread has been (rightly) filled with Puma specific talk, I may give it a clear out later and move the non FreeBOMBS specific stuff to another place, but not right now.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
Re: FreeBOMBS
I sign off for now.