Thoughts Wanted. Open Vendor Development Environment.

I've been developing the next version of the FOSSL Vending system for quite a while. My current stage of development is with the design of the structure of the scripts as well as how they communicate. Already, I have invested in a programmer and some cash to advertise this vending system. I expect to finish all the intricacies of design before March. I hope to finish testing the final product before the end of this year.

Before I can move further with its development, I need to clear this roadblock that affects this design. Not only would it be important for me, you will be affected as well. One of the clear design goals of this vending system was to allow for 3rd party replacements or addons to the original project. I don't want to create an environment that is unappealing to develop for. This is where you step in.

Attached are two documents and an illustration describing the environment of this vending system as well as the open communications protocol in which they communicate in. I urge you to seriously read this and ask questions or make comments.

For those involved here, I thank you for your time and consideration to take a look at what is stuck on my mind. I promise you wont be let down when I set this thing loose. ;3

Edit:

All the documentation can be seen @ this website...

http://tenkwear.110mb.com/FOSSLVendor/v1.0/index.html

My first, knee-jerk comment is to put these on a web page or at least use HTML instead of a Microsoft format. They seem to look ok in wordpad, and I'm pretty sure there are free viewers for MS Word files out there, but it's still an annoyance when 95% of such documentation is either HTML or PDF.

Sure thing,

Below is the web address of the Fossl Vending System Project. This place contains those two files as well as a bunch of illustrations and scribbles of what ideas popped into my head.

Enjoy :3

http://tenkwear.110mb.com/FOSSLVendor/v1.0/index.html

If I'd known you were using OpenOffice, I would have just suggested posting the .pdf files in the same way you did the .doc files.

In any event, I think the "What Parts" paragraph needs to go first, not last.

Why not get rid of the words "entities" and "devices" and just call them all modules?

As for the messages, you'll need a way to exchange version numbers. You'll also need a convention for people to add new messages without stepping on each other. Something like JOHNDOE.MESSSAGE if John Doe wants to add a new message to the protocol.

I think I get your point.

With the original plan,the communications protocol could only be determined on the spot with the link_message event in the "num" field. This makes it impossible to determine when the protocol travels through other mediums such as text chat, http, e-mail, or xml-rpc. Thank you for noticing. Its fixable, but it would only mean less space for the payload to travel in. damn size restrictions.

Your idea for individuals to add onto the protocol if needed seems like a nice idea and would make this project more attractive to develop for. Only issue I can see with that is that the developer might have to recode the core parts of the system to handle these messages correctly. I think I'll add this to the to-do list.

slightly off topic, but I'd beg you not to use .pdf acrobat is kida slow vs html and readabilty even on 1024x768 is very poor under 19in monitors... yeah I know upgrade upgrade =)

Don't worry Void singer, I gave a url to the whole thing above. Its now on my website for everyone to see.

While we are off topic and talking OpenOffice & Inkscape , give the free FoxIt reader a try for pdf's. A a lot less overhead and a million times faster for reading pdf's.

Nice job on the documentation showing the progression and thought processes on the project Ilobmirt. People ask every now and then just how we start large scripting jobs. Scite & LSLEditor rock but there are times when you still REALLY need a legal pad

Indeed you are correct Jesse. This isn't your average project that an average programmer can do on the top of your head. And yea, I've learned enough now to know documentation is needed.

I'm going to try updating the documentation tomorrow due to Kidd Krasner's point made about the communications protocol version being known only within linked messages. If you spot anything that might seem off to you don't be afraid to point it out. Already, I'm glad to have put it out here for more eyes to see.

See you tomorrow then with the update ^_^

Seconded! And AbiWord is a great and free word processor (for multiple platforms, btw) that can read and work with .doc files about a thousand times faster and with far less memory than OpenOffice.

Haven't dug into the docs much yet, will post thoughts when I finish that.

Sorry for the delay. Something popped up yesterday.

You should now see the updated version of the protocol available on the website. Thank you Kidd Krasner for pointing out the flaw regarding protocol version #'s as they travel across different mediums.

Whats been fixed was that I moved the versioning into the message that was traveling towards its destination. I also added in a protocol signature to the message to allow the vending system to know if it's either the official Open Vending System Communications Protocol, or if it happens to be someone's own deviated protocol.

The structure for it goes like thus...

protocolSignature | ProtocolVersion# | AddressCommand | Payload

An example packet would be...

OpenVendingSystemProtocol|1|ADDRESS d4a7dce3-5f15-60ca-8ce5-40da60b4da81 http:\\example.com\sales\FosslVendorServer.php|UNREGISTERVENDOR

The above message is the official Open Vendor System Protocol v1. Its addressed to example.com's web server from an in-world object, presumably, a vendor. The message tells the server that it is unregistering itself.

Not bad, eh?

Soo far, so good. I'll give this a few more days, before I move on to the individual design of the module processes.

wow, feel like an amature compared

/me goes to rewrite v1 after release...

Looks like the current protocol stands... I'm moving on towards module design.

~Tenk