Resource data interface

Discussion and suggestions regarding the site and/or forum.

Moderator: Forum Moderator

Post Reply
User avatar
Zimoon
Forum Moderator
Posts: 4817
Joined: Mon May 14, 2007 6:55 am
Location: Stockholm, SE
Contact:

Resource data interface

Post by Zimoon » Fri May 25, 2007 1:19 pm

Over time I believe an interface to add resource data from remote applications will be asked for. To prepare for it I suggest we come up with kind of an interface. In it's most simplistic way it could just be the rules on how to format simple text so it can be machine read. Next step could be the looks of an XML file wrapping the data, simple as that.

Then, what php or cgi URL to be called that can parse the data and feed the database.

---------------

I have a worry (which might stem from myself not have browsed around good enough): Currently, resource data that is added at this site, is that somehow feed into the SWGCraft.com database too?

User avatar
Sobuno
Developer
Posts: 2589
Joined: Sun Mar 25, 2007 2:17 am
Contact:

Post by Sobuno » Fri May 25, 2007 3:52 pm

You mean something kind of like the box used for /notepad entering on the swgcraft.com site jsut for applications instead (So they'd had to feed data into a php page or something)


And no, we only import data from SWGCraft.com, we don't export it atm

The only viable solution I can see for exporting the data back to their site was to use the Webservice he was developing.... But I just looked at it, and it only allows entries to SWGCraft.com Server

User avatar
Zimoon
Forum Moderator
Posts: 4817
Joined: Mon May 14, 2007 6:55 am
Location: Stockholm, SE
Contact:

Post by Zimoon » Fri May 25, 2007 4:46 pm

Kind of, however, I like to format-ize things so no ambiguous data is emitted. Whether that is such as
galaxy=bria
planet=corellia,dantooine, tatooine
name=qwerty
class=lub
oq=900
dr=545

galaxy=...
etc

or a full XML entry

Code: Select all

<resource>
  <class>lub</class>
  <galaxy>bria</galaxy>
  <planet>corellia</planet>
  <planet>dantooine</planet>
  <planet>tatooine</planet>
  <oq>900</oq>
  <dr>545</dr>
</resource>
is all the same to me. Perhaps XML makes it less prone to mistakes such as new-lines, etc.

I have been pottering with an application for quite some time and I will add the feature to upload data to sites that are interested. And if you know me I would prefer that te be one and only one site, since I do not believe SWG has a massive user base enough to split the resource data supporting guys over numerous sites. That will just inevitably lead to sparse data at all sites, but no one is really good.

That is also one of the main questions I have, until this site is good enough, do we support SWFCraft.com in parallel, or do we drain from it?

Personally I lack the time to potter together a small script that can manage to fool the data into SWGCraft.com, but apparantly it is possible since the SWGCU manages to do it, emulating a browser I believe.

User avatar
Sobuno
Developer
Posts: 2589
Joined: Sun Mar 25, 2007 2:17 am
Contact:

Post by Sobuno » Fri May 25, 2007 10:49 pm

Zimoon wrote:That is also one of the main questions I have, until this site is good enough, do we support SWFCraft.com in parallel, or do we drain from it?

Personally I lack the time to potter together a small script that can manage to fool the data into SWGCraft.com, but apparantly it is possible since the SWGCU manages to do it, emulating a browser I believe.
At the moment, we drain from it, I would like to export our data to their database when we go live (so as to keep the sites syncronized, and as a tribute to Trokk as he, afterall, was the guy that started it all)

User avatar
Zimoon
Forum Moderator
Posts: 4817
Joined: Mon May 14, 2007 6:55 am
Location: Stockholm, SE
Contact:

Post by Zimoon » Sat May 26, 2007 11:53 am

Sobuno wrote:At the moment, we drain from it, I would like to export our data to their database when we go live (so as to keep the sites syncronized, and as a tribute to Trokk as he, afterall, was the guy that started it all)
Fair enough :)

thunderloon
Novice Crafter
Posts: 1
Joined: Mon Jun 18, 2007 2:12 pm

about the data entry, separate steps

Post by thunderloon » Tue Jun 19, 2007 12:08 pm

shouldn't put the planets info on the fast resource entry

the fast entry should be JUST for the name, type and stats, then after it is in the database it would be simple to call it by name to whichever planet it is on


something like basic script code, even by e-mail to the site's address or could be made into a post on a forum for that specific purpose, this would allow the entries to be tracked by poster and checked directly but would also give the truely freaky harvestor junkies an immediate gratification.

so the first act would put the resource into the database on it's server's list, then have a page that allows for click-box activation per planet off of the primary "resources on server" list.

somehow I feel that the primary force stopping people from spamming fake resources has always been the need to manually enter each and every one of them...

Addtionally I'd like to vouch for my server, TCPrime... We don't want to have the resources for any other TC server spammed onto our database, so I'd say that taking extracts from the TC server list at swgcraft.com would be useless.

User avatar
Sobuno
Developer
Posts: 2589
Joined: Sun Mar 25, 2007 2:17 am
Contact:

Re: about the data entry, separate steps

Post by Sobuno » Tue Jun 19, 2007 2:02 pm

thunderloon wrote:Addtionally I'd like to vouch for my server, TCPrime... We don't want to have the resources for any other TC server spammed onto our database, so I'd say that taking extracts from the TC server list at swgcraft.com would be useless.
TCPrime shouldn't be recieving any resource contributions from the parser. The Test Center server should be getting the extracts from the Test Center server on SWGCraft.com

And the server "SWGCraft.co.uk" is getting the "SWGCraft.com" entries

CYCROFT

My idea of how SWG resource data entry should be...

Post by CYCROFT » Sat Jun 23, 2007 9:06 pm

Now, I did some programming but a long long time ago in a school far far away. But, we used to write GUI's (graphical-user-interface) for data entry applications all the time.

Basically, it's an entry interface designed for the most efficient entry of a specific type of data written in a common programming language like C+, VBA or other. Resource properties, in our case, have a uniform structure that, if the interface is done efficiently, could be entered in just a few seconds per resource with just a few tabs and keystrokes (here’s one of many guides on the net: http://www.iie.org.mx/Monitor/v01n03/ar_ihc2.htm).

The GUI may consist of a simple one-window executable application that a user can run, with SWG in tile mode for example, in the background while the user is sampling resources. The user will be able to sample a resource, enter the data and delete the resource sample or sample all the resources and then enter them all at once or paste in a survey droid report and fill in the blanks; the latter may take some doing but it’s an idea. The application would compile the data into whatever format(s) desired, tag the data with the user’s account information as well as date and time information etc., then transmit the compiled data file to the desired destination(s). The GUI could be programmed to put out multiple formats to multiple applications at multiple locations all from the user’s data set, require the user to enter data regularly to view the entire database (I really like this idea), auto-check the user’s data and require the user to proof-read the data before it is entered into the database and whatever else can be thought up to enhance the whole process.

What I like about this approach:
User friendly
Open system
No switching between applications
No coping or pasting (unless you use a survey droid report)
Data may be entered using multiple methods
Data may be entered efficiently
Data may be transmitted to multiple destinations
Data may be transmitted in multiple formats
Maintains uniformity, reliability and developer control

Also, minimal impact on server resources, bandwidth usage and no waiting for webpages to reload :P

User avatar
Sobuno
Developer
Posts: 2589
Joined: Sun Mar 25, 2007 2:17 am
Contact:

Post by Sobuno » Sat Jun 23, 2007 10:15 pm

Unfortunately, I am not a desktop programmer, merely a PHP coder :(

CYCROFT

Post by CYCROFT » Sun Jun 24, 2007 7:23 pm

Oh no, I totally understand...just throwing an idea out there.

User avatar
Sobuno
Developer
Posts: 2589
Joined: Sun Mar 25, 2007 2:17 am
Contact:

Post by Sobuno » Mon Sep 24, 2007 7:29 pm

Added SOAP functionality to the site the other day: http://www.swgcraft.co.uk/dev/soap/server.php

It's using the class called NuSoap which was the same one that Trokk began testing on the old SWGCraft site (Unfortunately, never got any far)

Oh, and Visual Studio seems to support it :) At least I was successful in making a small application in a couple of minutes (And I am very inexperienced in the art of desktop programming)

User avatar
Sobuno
Developer
Posts: 2589
Joined: Sun Mar 25, 2007 2:17 am
Contact:

Post by Sobuno » Mon Sep 24, 2007 7:34 pm

Oh, and suggest any functions we might want to add, I ain't all-knowing :P

Post Reply

Who is online

Users browsing this forum: No registered users and 37 guests