SDSS Subscription Server FAQ

[help][troubleshooting][howto][login]

 

1. Why is it called  SDSS?

2. Doesn't SDSS compete with Open Market's Transact Scenario?

3. Where did you get this idea?  What happened with SDSS v.1?  I've never heard of this before.

4. We have customized Softpages.  What is the process for incorporating them into SDSS?

5. Does SDSS take up additional siteDirector "Client IDs"?

6. OK, let's say we buy the notion that your solution is cheaper and easier.   That doesn't necessarily mean it is better.  What specific benefits does SDSS offer?

7. What about LivePublish?

8. Why all the legal mumbo-jumbo about use of your source code?  Any Internet development firm can do what you've done, right?

9. Your marketing blurbs all talk about how "simple" and "easy" SDSS is.  However, I just downloaded the help file and it is full of configuration options. What's the deal?

10. Hey, wait a minute!  As I understand SDSS, my siteDirector server must contact it in order to serve up the Softpages to the end-user.  Isn't that going to take a long time?

11. How can I test the performance of SDSS with my system?  Is there a demo?

12. Why do you charge such a high percentage to use your merchant account for transactions?

13. When do I create a SubProduct Record?

14. Why do you have a Product Code and a SubProduct Code?  What's the difference?

15. Do I need a SubProduct Code for Infobase or File Download Subscriptions?

16. What's the difference between a File Download Subscription and a File Download Purchase?

17. What are the browser requirements for my end users?

18. Why do you use numbers in your date fields instead of dates?

19. Why doesn't my company logo appear on the subscription order page?

1. Why is it called "SDSS"?

This service was originally called the "siteDirector Security Server" (SDSS) because it was initially designed to handle Folio Views Infobases.  Since that time, several years ago, we have evolved to handle other content management packages.  The service still has the same goal:  to provide a complete subscription management system for electronically published information.

We are not trying to compete with E-Store application providers such as Yahoo and Excite -- or even Open Market.  We designed SDSS to cater to the needs of Electronic Publishers, specifically Folio Infobase Publishers.  We want to use SDSS as a vehicle to move Folio and other Publishers towards e-commerce.  Some of them may want to publish their infobases over the web.  We think content management packages like siteDirector, LivePublish, NXT3, dtSearch, and others are the best mechanism for that.   In our experience, we have seen that other Publishers may  want to offer their Infobase CDs online, or the ability to download updates to their existing infobase subscriptions, or just simply sell subscriptions online which are delivered offline.   We want SDSS to be able to handle all of these possibilities.  While most e-commerce systems are designed for brick and mortar establishments who now want to sell their inventory online, SDSS was designed for information publishers, specifically Folio Publishers.  This is our niche.

2. Doesn't SDSS compete with Open Market's Transact Scenario?

We don't believe so.  SDSS was designed as an easy, inexpensive, low-end and entry-level entrée to e-commerce enabling Folio Infobases.  It requires no programming, no plug-ins, no additional software (beyond siteDirector) at your site.   It is basically a software product which runs on our servers, but is totally configurable by you via your browser.  It is a 100% Internet E-Commerce solution:   That is, it runs totally on the Internet, you administrate it via the Internet, and it enables you to sell information products and services to your customers over the Internet.  We think this makes it a totally unique option for siteDirector Publishing.

3. Where did you get this idea?  What happened with SDSS v.1?  I've never heard of this before.

Actually, we give Open Market credit for part of the idea.  We developed the first siteDirector Security Server two years ago, as a solution to e-commerce enabling Folio Infobases over the web. This development was borne of our frustration in trying to find an OM CSP (Commerce Service Provider) we could work with to make e-commerce a reality for "low-end" Folio publishers (you know, the regular guys). We used it primarily for our siteDirector hosting clients and other in-house e-commerce applications which involved Folio products.  Earlier this year, it finally dawned on us that the scenario we had developed would work with any siteDirector server on the Internet. 

On Open Market's website (http://www.openmarket.com), there is a link to "Keenan
Report:Winning the Merchant Wars
" leading to a report titled "The e-Merchant Opportunity of 1999".  In "Part 1: The e-Merchant Stack" of this article, Mr. Keenan writes:

"To handle the onslaught of new customers e-merchant service providers will need
to package together technology and services to create a simple set of services that
makes any small business into an e-merchant will little effort. Whoever can make it
simple and financially viable to make the move online will be best able to line up an
array of e-merchants in their stable that will cater the diversifying needs of online
buyers."

Further along, it continues:

"For e-merchants, ease of use and low cost define the value propositions that
e-commerce apps need to deliver. E-merchants also need to completely control the
operation of their e-commerce apps with a simple web browser, avoiding
client-server or other specialized applications employed by high-end e-commerce
site operators."

We agreed with these statements, and endeavored to turn our SDSS into just such an E-Commerce Application for siteDirector Infobase Publishers.  Hence, SDSS Version 2.   We hope we have succeeded in that effort.

Please visit Keenan's website and read the entire report.  We also highly recommend that you visit Open Market's site to understand their siteDirector E-Commerce options as you evaluate SDSS.

4. We have customized Softpages.  What is the process for incorporating them into SDSS?

From our Help file we have the following statement: "If you don't understand anything else about this process, please understand this: Every sD Frame Softpage that can be used to access your infobase in an intelligible way MUST point to an SDSS Softpage."  Any Frame level Softpage you are using must be replaced by an SDSS Softpage.  If you are using customized pages, and wish to continue using these same pages, then SDSS must be updated to accommodate them.  We will need you to send us copies of the pages in question, and we will send you SDSS Softpages to replace them as "Softpage Aliases".  We charge $25 per Softpage for this service.   The only Softpages which need to be customized are those which are equivalents to these default sD pages:

Doc_Frame_Pg42.htm
Document42.htm
Browse_Frame_Pg42.htm
All_Frame_Pg42.htm
Search_Frame_Pg42.htm
Toc_Frame_Pg42.htm
ref_BrowseView42.htm
ref_SearchView42.htm
ref_MainView42.htm

5. Does SDSS take up additional siteDirector "Client IDs"?

Yes.  It takes one additional client because our host makes some calls back to your server.  Mostly, however, your end-user makes the requests to your siteDirector server.  However, since our host is the same IP, the client ID should not change.  We simply prevent the page from being displayed until the user is logged in.   However, there are some issues with the whole sD client ID setup which are beyond us -- like why an additional client is sometimes added when a user refreshes.  Bottom line: the more client IDs you are registered for, the better.

6. OK, let's say we buy the notion that your solution is cheaper and easier.   That doesn't necessarily mean it is better.  What specific benefits does SDSS offer?

The SDSS subscription process for end-users requires no intervention on your part.   It takes end-users through the signup process, and expires them, automatically.   Once the subscriptions are set up, SDSS handles everything from there, 24 hours a day, 7 days a week. You receive automatic e-mail notifications on all new signups/purchases/subscriptions. SDSS also sends out automatic renewal notices to your end-users.   SDSS offers you COMPLETE control over your service options by browser.  SDSS records, and lets you retrieve, the most complete information available on who is accessing your infobases, when, and to what degree.  We actually allow you to make direct SQL queries to our database to retrieve any information you desire (well, almost any information -- we can't let you see *everything*). 

Let's put it this way: SDSS was designed by people who have been publishing Folio Infobases since the mid-80's, and hosting Infobases over the Internet since *before* Version 1 of the original Folio WebServer.  SDSS was originally developed by us for us, so you can imagine all the features we put in to make our jobs easier.  Now, imagine all the features put in to make *your* job easier as well.  It was designed by publishers for publishers.  That, in our humble opinion, is a compelling reason to at least check out SDSS.

7. What about LivePublish?

We believe that LivePublish is a great product.  We do intend to incorporate it into the SDSS system in the long term.  However, right now, in OUR opinion, the best e-commerce solution for infobases is with siteDirector.  It has a track record,   an installed customer base, and a proven ability to publish Folio 3.x and 4.x infobase over the web.  Of course, we could be wrong.  You, the market, will certainly let us know in short order.

8. Why all the legal mumbo-jumbo about use of your source code?  Any Internet development firm can do what you've done, right?

Right.  We, as you, believe in the free and unfettered flow of information.   But look at it this way:  You are a Folio Publisher.  You publish the State Code of Montana.  Any competent Folio Publisher can do this.  He/She can even study your infobase for ideas on how to put it together.  But, is it OK for them to steal your Flat File, run it through a parser to change the look and feel, then begin selling their version of the State Code of Montana against yours?  We didn't think so.  We just want to give notice that if you steal our stuff, we're gonna come after you.   I mean, it's not like we are trying to patent the term "Internet Commerce" or anything like that.

9. Your marketing blurbs all talk about how "simple" and "easy" SDSS is.  However, I just downloaded the help file and it is full of configuration options. What's the deal?

Can you spell "c-o-m-p-r-e-h-e-n-s-i-v-e"?  If we could decide the name of your subscription, the amounts to charge, the duration of the subscriptions and so on, it would only take 5 minutes to get your infobase secured and e-commerce enabled.   Unfortunately, you may have some ideas of your own.  Once you obtain an SDSS Client Source Code and username/password, you only need to define the subscription and the infobase(s) which are a part of the subscription.  For infobase subscriptions, that's it.  When the SDSS Softpages are installed at your end, you are ready to rock and roll.

10. Hey, wait a minute!  As I understand SDSS, my siteDirector server must contact it in order to serve up the Softpages to the end-user.  Isn't that going to take a long time?

It could.  Just like several factors can cause your sD server to respond at different rates (time of day, traffic, server utilization, etc...).  However, we generally estimate that the time increase to deliver a SDSS page as opposed to a straight siteDirector page will be between 30% and 75%.  You are right, your sD server has to contact SDSS, but we have a Java multi-threaded application running at our end which can serve the page several times faster than your sD server does.  It can do this because, unlike sD, it doesn't require the httpd service processes.  The major time impacts will be with the connection between your sD and our SDSS, and the time between our SDSS and the end-user.  Our feeling is that with at least T1 connections on both sides of the connection, the sD to SDSS to sD connect should be fairly instantaneous.   And remember that your sD server is no longer actually sending the main page to be displayed, SDSS is.  Also, with more users gravitating to DSL, Cable and other high speed connections,  whatever appreciable time delay there is will soon disappear.

Please note that not *every* page requires a contact to our server.  The most frequently used pages are called directly from your server.  Only the less frequently updated frame and search pages require calls to our server.

Finally, if normal SDSS performance is simply unacceptable at your site, and we agree with that determination, we do have a version of the SDSS program which can be run locally on your sD Server or network.  Because it is written in Java, it is platform independant and can be installed under NT, Unix, Linux, Windows 95/98,. etc...   However, all other SDSS requirements remain the same and the SDSS database also remains on our server.  The only difference will be that your SDSS Softpages will point to your SDSS server instead of ours, thus slightly reducing the amount of time it takes to communicate between your sD server and SDSS.  This scenario, if necessary, will require the Java Runtime Environment (JRE) and JDBC installed at your site as well as an OpenLink Multi-Tiered ODBC Driver and license.

11. How can I test the performance of SDSS with my system?  Is there a demo?

There is no demo.  SDSS works.  Period.  It is a 100% Internet-based service.  If you are on the Internet, you can get to SDSS and it can get to you.   The real question is: how fast?  As stated above, there really is no guaranteed response time because there are too many variables.  Someone who's decision to use SDSS boils down to whether it takes 1 second or 2 seconds to connect is probably someone who needs to look at another solution.  We feel the benefits are so great that you are either going to commit to SDSS or not.

The one scenario where SDSS may have a problem is when an end-user logs on from a proxy server that is changing the IP address announced in his browser.  This is rare, but it does happen. This is an issue to be resolved between the end-user, his ISP, and his browser. SDSS, while using cookies, relies primarily on session IP addresses to identify end-users.  This is, in our opinion, the best method for providing HTTPD access.  

There is, however, a tool you can use to at least get some feel for the connect time.   You can drop down to DOS on your NT server and enter "ping host2.scbbs.com".  Try pinging other sites as well such as Yahoo, Netscape, CompuServe, etc...  Record the results.  Do this a few times over a few days.   This will give you an idea of how long it takes your server to connect to the SDSS server. 

There is also a test sD server running at: http://209.125.230.135/cgi-bin/om_isadll?infobase=test.nfo&softpage=Browse_Frame_Pg42

This sD server is not on our network and has to travel across the Internet, as yours would, to connect to SDSS.

Finally, if performance is a real issue at your site, we do have an alternate solution.   See the end of Number 10.

12. Why do you charge such a high percentage to use your merchant account for transactions?

Because, quite honestly, we do NOT want to be the Merchant of Record (MOR) for your credit card transactions (which is what we are so long as you use our merchant account).   SDSS is designed to get you set up to do e-commerce in a few minutes.   However, if you are going to really be an E-Merchant, you should have an E-Merchant Account.  We want to get you online as quick as possible, but we also want to discourage you from relying on our merchant account to sell your stuff.

13. When do I create a SubProduct Record?

Only when you have an item you wish to make available via the SDSS Shopping Cart. This would be either a file download or shipped product.   A SubProduct Record is not required for infobase or file download subscriptions.

14. Why do you have a Product Code and a SubProduct Code?  What's the difference?

The Product Code identifies a general class of product.  The SubProduct Code identifies individual items which can be purchased.  Each SubProduct must have a main Product Code.  In other words, the Product Code is the father, the SubProduct Code the child. 

15. Do I need a SubProduct Code for Infobase or File Download Subscriptions?

No.  Each new Subscription Record is allocated a unique code.  This code, along with the pricing you enter when you create the record, is automatically used as a SubProduct Record, under the main Product Code "O".

16. What's the difference between a File Download Subscription and a File Download Purchase?

A File Download Subscription gives end-users access to a file over a period of time.   It is intended as a mechanism for delivering updates to infobase or other software products on an on-going basis.  A File Download Purchase via the shopping cart is intended as a one-time purchase of the file in question.

17. What are the browser requirements for my end users?

We have tested SDSS with Internet Explorer 4.01 and 5.0,  Netscape Navigator 4.04 and 4.5.   We know it will NOT work with IE 3.0.  You can access our demo "test.nfo" to see how it may react in your browser.  Use the username "demo", password "demo".

18. Why do you use numbers in your date fields instead of dates?

SDSS is comprised of a number of technologies: Java, JavaScript, Perl, SQL, ODBC, JDBC and Perl DBI, running on both Windows NT and Linux operating systems, using Microsoft Access and IBM DB2 databases.  Trying to come up with a common date format for all of these different platforms was a nightmare.  We finally decided on using the standard Perl "time()" function, which also works quite well with Java.  This date format is standardized, and accurate to the year 2030 (at least while limited to 32 bit systems).  Everywhere a date entry is required in SDSS you have a date conversion utility which allows you to enter the date in "English".

19. Why doesn't my company logo appear on the subscription order page?

The order page is a secured page,  which means all elements in it must come from a secure server.  Your logo comes from the URL you entered into the Logo URL  field of your Source Record.  For it to be secure, and appear on the order page, your logo needs to be on our server. Please contact your SDSS System Administrator in order to upload your logo to him.  Once uploaded, you should change your Logo URL to:

    https://dns.scbbs.com/images/<your logo filename>

(Please don't forget that this is "https", not "http").