Public Speaker, New Media Expert, Thanet's leading independent journalist, SEO, Web Developer and business to Internet interface expert. Also a father, a geek, a blogger and friendly face. An Agent of Change.

Archives

This item continues my thoughts from "WiB -
What is Blog" where I found myself considering the blog item
as an object. Now I wish to look at what we could do to
create a reasonable API specification for dealing with such objects.
Which in my opinion, is a good first step towards creating a blog server and protocol
specification.

I will be using notation that is a
little bit PHP and a little bit make it up as you go.
What you will see is copied directly from my working notes
and then tidied up a little for the common good (as it were). I have
tried to assume as little as possible and have made no assumptions
about how the data should be stored.

Let us assume
that we create our connection in PHP with $localvar = new
thing_connection(); so that our var now holds a connection to the API
server. There should be a number of basic instructions that
should be publicly available. When I say publicly I men that the
API are exposed not that they should be freely accessed.

For
example all instructions should take a user identifier and pass-key
data which can include API code, password or SHH fingerprint,
PGP-Public Key, or any such security that you see fit to run in your
API and can be readily added by the available clients. As
there are no clients that exist there is little to limit what can be
set up.

I also ran into the idea of URI which are
like URLs. Actual a URL is a form of URI but a URI does not
necessarily know where the URL for identified thing is. A URL is a
uniform resource locator, and a URI is a uniform resource identifier.
You can also have URN (names).

This was
where I met the real world. Post Pages, Item Pages - call
them what you will these pages that contain the post and the comments
are the ones pointed to by the permalink. In a way the PERMA
link is the id for a URL, URI and URN to the HTTP presentation of the
item (item being a thing). As such I feel it would do well
for us bloggers to mark perma links and the resultant pages with a
domain specific RN (Resource Name).

This will serve
to tell search engines where the HTML presentation is to be found and
perhaps the XML (feed) presentation of the item. Hopefully
the search engines will stop relying on good assumptions that were
perfectly true five to ten years ago but with the world of dynamic data
to page are less than perfectly true now. Google might be the
best but it is the best at using an out dated assumption - the
assumption that a page is a discrete unit.

There is
the potentiality to need to call for a named resource by URL such that
blog://example.com/some-id-system might be the final URL but if we were
to create serverless names they might look like
blog://abfcd64bdf6af6435f5567.0ad109de.some-id-system - such a protocol
would simply extend HTTP via, say, REAT, SOAP or some other XML
transport. I was mainly thinking xmlrpc when creating this
although that initself would need to be packaged within and so might
not be so good.

Because the API needs to send and
recieve no just HTML and XML data but MP3, JPEG and other attachments
(think podcasts, vedio blogs and image streams) that should be embeded
within the thing. This led me quite quickly to the
realisation that the thing must be able to be sent and receved useing
the mime type "multipart/related" which is how email is (generally)
sent.

I will expand more on this later - I want to
focus on the API that the core system would use however this idea of
public RNs will be vital to the concepts that are contained herein.
Concepts that would allow peer-2-peer blogging, and other new
ideas yet to be conceaved.

[1] This would pre-suppose that some sort of thing
clustering was taking place[2] This could be a better idea
allowing the definition of the meta data item group[3] this
may not be implimented on all API and where not GROUP should be assumed
to be authenticated-users [4] This allows the API to be
extended and allows encapsulated calls to be made from thing types on
the events

The get response should
fall into two parts the thing core and the thing meta. If it
came as an array it might look like this

$array['data']['data']
- the actual data of the thing

$array['data']['meta']
- all the meta data given

While the data itself
should be faily obviouse some words, I feel, are needed on the metadata.

Mime
- the format of the data

title/human-readable

timestamps

created

last-access
- also contains the data who

last-changed - also
contains the data who

things - a
collection of things embeded within the thing this should be returned
as unique ID

groups - collection of assigned
grouping values which allows the controller to create a taxonomy for
things

indexing - format TBA data refering to the
indexing of the item as part of the searchable whole possibly private
to the API

Permissions - used by the API

Owner
- used by API

UserGroup - used by API

As
?I have mentioned users, permissions and groups a few times I think it
is as well that I talk about what I think they are and how they might
work. They reflect the way in which FTP users have interacted with unix
webservers for ever such a long time and as such the math and
commonality should ensure that they are readilyt understood.
While a root and active user are required to exist on an API
install a simple authen ticated and anonmouse users as dafault should
be enough for the groupings. API administrators that wish for
greater security can create aditional managment options by the creation
of user groups and by setting them as part of the core specification
the scope for such creation exists fom the start.

Classicly
a few things could be created and defined as default - Blog, Comment,
Post and possibly user. Blog would be a container thing that
would hold all the other posts but if we specify for a UI that supports
"views|" [5] we could ignore the demarkation of ridged blog groupings
and impliment the WSOGMM. However Comment and Post do have
special needs. Post by default has the create and write
allowences set to owner (and root) only while comment is world
creatable, owned by the owner of the parent thing who is the only user
that can edit and delete (set to null).

It was at
this stage in the thrashing nout of ideas that it became clear that
things should be considered to have events. "Things have
events" I wrote "the API needs to respect those events and action them
according to defined API connection calls listed within the data."
By this I mean that there are four or five clear moments that
classes that extend the core API should be able to subscribe to.
These are the same events that new classes of things can use
to create more advanced logic to the data form.

Additionally
it occours that to keep things free from bonding to any given platform
exlusivly a thing specification "language" might be needed.
This could be a simple XML document that specifies sub-things
and other basics. This would be easy to "parse" for actions
and check for thing-type-casting.

I have taken yet another step to stop the utter ******* that have been hammering my admittedly low powered server. This time I have installed a firewall bringing me up to 85% memory usage. Remember folks that at 75% usage you need to upgrade so I expect slowness and all that but the extra 2.4% is worth it.

One big issue was that I had assumed that the physical ethernet adapter for the server was eth0 as is default under *nix. however APF firewall could not confirm that "...eth0 is routed to a network, aborting". And it was true. After discovering a command that would show up the IP addresses for each adapter I learned that on a virtual server things are set differently.

So for the first time ever the ethernet adapter is correctly set in cpanel (such a vital setting!) and the firewall now actually works. It's running now.

It is only time now that will show if the server is now going to run with any stability.

One last not if the server takes a disliking to you then the firewall will block your IP address for 5 minuets and reset this value if you try to talk to it in that time. Make a cup of joe and then have another go. If you want to do likewise then this is the page that helped me most.